SCRUM Methodology in 100 words
Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
The SCRUM methodology has been used for:
- Self-organizing teams
- Product progresses in a series of month-long “sprints”
- Requirements are captured as items in a list of “product backlog”
- No specific engineering practices prescribed
- Uses generative rules to create an agile environment for delivering projects
A sprint (or iteration) is the basic unit of development in the Scrum methodology. The sprint is a time-boxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common; a constant duration leads to a better rhythm and a much more precise prediction about “what’s coming” next from the team members. The product is designed, coded and tested during the sprint.
There should be no changes during a sprint. Each sprint starts with a sprint planning event that aims to define a sprint backlog, identify the work for the sprint, and make an estimated forecast for the sprint goal.
The SCRUM Framework
There are three core roles in the Scrum framework. These are ideally co-located to deliver potentially shippable product increments every sprint. Together these three roles form the scrum team. While many organizations have other roles involved with defining and delivering the product, Scrum methodology defines only these three.
The product owner represents the product’s stakeholders and the voice of the customer, creates roadmaps, is accountable for the backlog, and maximizing the value that team delivers to the business. The product owner should focus on the business side of product development and spend the majority of their time liaising with stakeholders and should not dictate how the team reaches a technical solution.
- Define the features of the product
- Decide on release date and content
- Be responsible for the profitability of the product (ROI)
- Prioritize features according to market value
- Adjust features and priority every iteration, as needed
The Scrum Master
The scrum master helps to ensure the team follows the agreed processes in the Scrum framework, often facilitates key sessions, and encourages the team to improve. The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.
- Represents management to the project
- Responsible for enacting Scrum methodology values and practices
- Removes impediments
- Ensure that the team is fully functional and productive
- Enable close cooperation across all roles and functions
The Development Team
The development team is responsible for delivering potentially shippable product increments every sprint (the sprint goal).
- Typically 5-9 people
- Cross-functional: programmers, testers, UI/UX designers, etc.
- Teams are self-organizing
- Team selects items from the product backlog they can commit to completing
- Sprint backlog is created
- Tasks are identified and each is estimated (1-16 hours)
- Collaboratively, not done alone by the ScrumMaster
- High-level design is considered
|As a vacation planner, I want to see photos of the hotels.||
The Daily SCRUM
Any impediment (e.g., stumbling block, risk, issue, delayed dependency, assumption proved unfounded) identified in the daily scrum should be captured by the scrum master and displayed on the team’s scrum board, with an agreed person designated to working toward a resolution (outside of the daily scrum). No detailed discussions should happen during the daily scrum.
- Not for problem solving
- Whole world is invited
- Only team members, ScrumMaster, product owner, can talk
- Helps avoid other unnecessary meetings
- Everyone answers 3 questions:
- What did you do yesterday?
- What will you do today?
- Is anything in you way?
- These are not status for the ScrumMaster; They are commitments in front of peers
The Sprint Review
- Held at the end of each sprint
- Team presents what it accomplished during the sprint
- Typically takes the form of a demo of new features or underlying architecture
- 2-hour prep time rule
- No slides
- Whole team participates
- Invite the world
- Periodically take a look at what is and is not working
- Typically 15–30 minutes
- Done after every sprint
- Whole team participates
- Product owner
- Possibly customers and others
- Start / Stop / Continue – The whole team gathers and discusses what they’d like to:
- Start doing
- Stop doing
- Continue doing
The product backlog is what will be delivered, ordered into the sequence in which it should be delivered. It is visible to everyone but may only be changed with the consent of the product owner, who is ultimately responsible for ordering product backlog items for the development team to choose.
- The requirements
- A list of all desired work on the project
- Ideally expressed such that each item has value to the users or customers of the product
- Prioritized by the product owner
- Reprioritized at the start of each sprint
|Allow a guest to make a reservation||3|
|As a guest, I want to cancel a reservation.||5|
|As a guest, I want to change the dates of a reservation.||3|
|As a hotel employee, I can run RevPAR reports (revenue-per-available-room)||8|
|Improve exception handling||8|
Managing the Sprint Backlog
The sprint backlog is the property of the development team, and all included estimates are provided by the development team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like to do, in progress and done.
- Individuals sign up for work of their own choosing
- Work is never assigned
- Estimated work remaining is updated daily
- Any team member can add, delete or change the sprint backlog
- Work for the sprint emerges
- If work is unclear, define a sprint backlog item with a larger amount of time and break it down later
- Update work remaining as more becomes known
Sprint Burn-down Chart
The sprint burn-down chart is a public displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.
Release Burn-up Chart
The release burn-up chart is a way for the team to provide visibility and track progress toward a release. Updated at the end of each sprint, it shows progress toward delivering a forecast scope.
The Scrum methodology is designed to optimize team satisfaction and productivity, product quality, responsiveness to customers, and transparency for stakeholders. The key practices that enable these benefits include de-emphasizing work on non-deliverable items, implementing and finishing each Story in a Sprint Backlog in rank order, working in short Sprints of 2-4 weeks, and making past, present, and future project information available to all stakeholders.
So, when starting a new project, not only a Software Project, SCRUM methodology can most likely be suitable for you. It helps you organize your work and also have a feedback discussion with your clients/peers.