Scrum is an agile project management methodology that plans and executes in small iterations. Doing this allows for changing and improving the plan during the development lifecycle. However, it has also been criticized for overscheduling meetings. So, it’s important that these guidelines are used in a way that fits the unique needs of the organization.
Typically, scrum teams are small, consisting of three to nine people. The development team is typically a cross-functional team so that if one resigns, another team member could take over that person’s work.
All work is divided into sprints, which are iterations of a scrum project that last from one to four weeks. Sprint Zero is the first sprint intended to prepare the development environment and perform preliminary planning for the first sprint.
Scrum Sprint Checklist
Step 1: Create & Prioritize Product Backlog
The Product Owner (PO) is typically responsible for creating and prioritizing the product backlog. The PO is the visionary for the project who understands business processes and connects the stakeholders with the development team, oversees completed work, and communicates goals to the development team.
The product backlog contains the “stories” and features, yet to be completed in the product. Each item in the product backlog is prioritized based on customer or stakeholder value and its immediate impact. For example, valuable or impactful items should be near the top. Smaller features that are easier to complete and may quickly yield value and ROI are included. The items from the product backlog will eventually be committed to the sprint backlog and worked during the sprint.
User stories describe what the different users will do with the software. For example, “as a user, I need to click on a button that will download a file.” This is usually collected during the information requirements gathering phase of the project and becomes the acceptance criteria by which the feature is determined to be complete.
Step 2: Backlog Refinement
During backlog refinement, team members are responsible for estimating the amount of time and effort required to complete tasks. To do that, team members assign “story points” to each task as a value of the Fibonacci sequence (e.g., 1, 2, 3, 5, 8, 13, 21), which represent the amount of effort required to complete a task. Low effort tasks are assigned low points (1) and high effort tasks are assigned high points (21).
Story points usually represent hours of work:
- 1 point = 2 hours per individual.
- 2 points = 5 hours per individual, or .5 days for two people.
- 3 points = 10 hours per individual, or 1 day for 2 people.
- 5 points = 20 hours per individual, or 1.5 days for two people.
- 8 points = 40 hours per individual, or 3 days for two people.
- 13 points = 80 hours per individual, or 5 days for 2 people.
Team members could make this determination independently. Or it could be completed during a refinement meeting as an average of all the team member's estimates.
Step 3: Sprint Planning
During sprint planning, which usually happens weekly, the Scrum Master (SM) sets a fixed Sprint duration based on how many points could be completed during the sprint. The Scrum Master, then, reviews the backlog for priority items and assigns those tasks to the upcoming sprint. Stakeholders may be included in this process as part of the change control process. The primary job of the Scrum Master is to keep the team focused and bring up any impediments to progress during the scrum meetings.
Sprint planning should also be used to perform capacity planning. Developers will review their current capacity, including hours available to work or any time off, to ensure they are available to perform the work.
Step 4: Progress Visibility
The Scrum Master may use a Scrum Board or storyboard to visually represent the progress taking place. This is often divided into three phases of work: Do, Doing, and Done. The Do column contains the planned tasks. The Doing columns contains items being worked on. And the Done column contains items that are completed. Items placed in these phases are usually color-coded cards. Green cards are features, white cards are user stories, yellow cards are tasks, red cards are defect cards, and blue cards are technical debt.
The Scrum Board may also be divided into swim lanes, the top being the fast path and the bottom being the slow path. As developers progress from left to right in their lanes, they pass through the Backlog, In Progress, Quality Assurance, and Complete.
Quality Assurance (QA) performs the acceptance testing based on the acceptance criteria to ensure the software works as expected using a test environment that mirrors the production environment. Anytime the acceptance criteria are not met, a defect card is created and assigned story points.
The Scrum Master may also update a Burn-down chart daily, which consists of Points on the Y-axis and Days on the X-axis to represent the points that remain to be completed.
Step 5: Daily Standup
Lead by the Scrum Master, the daily standup meeting (Scrum Meeting) is a 15-minut meeting to receive feedback on what one did yesterday, what one will do today, and what obstacles stand in one’s way. This helps the Scrum Master to determine what could be done to help the team finish the Sprint on time.
Step 6: Sprint Review / Demonstration
The Sprint Review usually occurs at the end of the Sprint. The team demonstrates the work completed during the Sprint to get feedback from the stakeholders, like management, clients, or the product owner, to approve or disprove all the features added during the sprint. This also gives stakeholders the opportunity to ask the developers questions about the new features or bug fixes.
Ultimately, the projects should aim to include the minimum set of features required to satisfy the requirements, known as the Minimum Viable Product (MVP), as well as those features that have value to the customers, known as the Minimum Marketable Features (MMF).
Step 7: Sprint Retrospective
In a sprint retrospective meeting, team members are required to post what went well, what didn’t go well, changes that need to be made, actions items, and congratulations for doing a good job. This also provides developers with the opportunity to discuss any issues that occurred during the Sprint that remain to be addressed.
While the requirements for completing a project may be complete, the project may still contain technical debt. This is work that remains, such as refactoring code to make it maintainable, including security features, or building out a more robust development or deployment environment. Technical debt is usually pushed into future releases.
Additional Resources