13 Considerations for Agile Scrum Sprint Planning

Updated

Agile Scrum teams break down their work into smaller, more manageable pieces of work known as Sprints. Each Sprint is typically a self-contained iteration with its own requirements, development effort, and testing. By delivering software more frequently, in bite-sized pieces, issues can be detected earlier, and changes can be made as needed without having to wait till the end of the project. Sprints also make the team more responsive. The team can also react to changes such as new requests, market changes, etc on a much faster basis versus in the Waterfall development methodology.

The Sprint Backlog (not to be confused with the Product Backlog or Release Backlog) is the list of work items that the Development team commits to getting done in that particular Sprint. Creating the Sprint backlog is a collaborative effort between the Product Management team (PM) and the Dev team.

The Product Owner, or the Product Manager, creates a list of items that they would implement, aka the Sprint goals. The Dev team reviews this list, breaks it down into estimable chunks, and then determines what can realistically be completed in the Sprint. With collaboration and some negotiation, the Sprint Backlog is eventually defined and committed to.

How a Sprint is defined can vary from team to team. But it is important metrics be set in place to measure the success of the Sprint, as well as to determine any potential issues. The right metrics can point out issues or bottlenecks early on in the Sprint so that those can be rectified quickly.

1. Consistency of Sprint Duration

Sprints are meant to be time-boxed, meaning the duration is defined upfront, and once defined, this duration does not change. Teams do what they can to achieve the work they’ve defined in that time period. Many teams choose 2 weeks as their Sprint duration, although some teams could go for up to a month. What’s important here is not how long the duration is, but that it remains consistent.

A consistent Sprint duration enables teams to get better at estimating what they can achieve in that time period. Better estimation helps improve the success rate of the sprint in achieving its planned goal.

2. Product Roadmap Visibility

Product Management Hygiene and practices have the most impact on Agile Scrum Sprint Planning. Since all new work originates with a specification by PM, lack of clarity and detail has several downstream impacts that could jeopardize the ability to deliver on sprint commitments. The PM team defines the overall goal based on a number of criteria and these must be monitored and measured.
The PM team generally has a high-level roadmap of the work that needs to be done in the next few releases. This roadmap is then broken down into Epics, which are further broken down into smaller user stories. Giving the Dev team visibility into the full roadmap helps them get a better understanding of the bigger picture of the product direction, so they can make technology and architecture decisions accordingly.

3. Requirements Clarity

The Requirements doc is typically on a Release level. In agile development, It does not need to be too detailed or complex. It should however include the user stories, their priorities, timeframes, interactions, and other considerations so the Dev team can understand how the different pieces fit together. It can also include customer interviews, product wireframes and mockups, and other related content for full context. The Requirements document for a particular release is typically not updated often but should be flexible enough to accommodate changes if needed.

4. Balanced Sprint Distribution

For every Sprint, the PM needs to decide how much they are going to focus on user Stories for new features versus bug fixes. On one hand, new features help progress the product forward. But bug fixes are critical for better customer experience and to fix defects. A balanced Sprint should include a mix of both.

5. Detailed User Stories

The user stories should be well-defined, clear, and concise to avoid any confusion. This ensures that the engineers know the details of every item and exactly what to build, and ensures that the code meets the PM specification and the customer needs.

6. Objective Prioritization

Once the User Stories are defined, Priorities should be assigned to each of the user stories. This helps the Dev team prioritize their workload. Priorities can take multiple factors into account including the business priority, customer requirement, customer escalation, competitive need, the interaction between stories, etc. The eventual priority list can include stories from the same epic, or across different epics, based on the Roadmap.

7. Include Acceptance Criteria & Test Cases

The Acceptance Criteria (AC) help define what work items are considered “Done”. This can include metrics such as the time required to complete an action. It can also include QA notes so the engineer can test the code before they move it to Done.

The clarity and completeness of output from the PM are critical to the success of the Sprint. When all the details are included, everyone is in sync, and this minimizes back and forth between teams for questions and clarification and can speed up the process. It also ensures that the code built by the engineers meets the PM specification and the customer needs. Hence it is important that the PM Output be measured and quantified.

It is important to be able to answer the following questions:

Are requirements up to the mark?
Are there any acceptance criteria missing?
Are test cases missing?
Are the priorities defined clearly?
Does the engineering team have everything they need?

If there is a critical field that is missing, there should be some checks and some workflows set up that send reminders to the PM indicating that further input is required. You can also compare requirements flow from various teams to see if certain ones are doing better and to figure out areas of process improvement.

8. Story Point Values

After the Dev team gets the scope of work from the PM team, they need to break it down further to determine what is achievable in the Sprint. This is also a critical step since it forms the basis for negotiations with the PM team on what is feasible to complete in the sprint. There are a few factors that go into this:

There should be a consistent way of calculating the story points for a particular work item. Many teams use the “Fibonacci Sequence” (1, 2, 3, 5, 8, 13,....) for available story point values. It is important that once the potential values are determined, the team does not deviate from them (for example, teams could try to compromise between 2 and 3 by assigning an item 2.5 story points. This should be flagged and not be allowed).

9. Estimation Accuracy

Estimation is a very difficult exercise, and there is always a chance of getting things wrong. Typically, the more complex the work item, the harder it is to estimate. For this reason, teams should avoid items with a high number of story points (e.g. above 5 story points). Such items should be broken down into smaller items whenever possible, making them easier to estimate and achieve. This also promotes iterative development where large tasks are broken into smaller chunks to enable predictable estimation and execution.

10. Story Points Calculation Bias

Story points are units used to define the amount of work required to complete a work item. Story points are calculated based on the number of hours estimated, the complexity of the item, and its risk factor. For each Sprint, a max number of story points is defined, and this should not be exceeded.

Teams often use the “Planning Poker'' method to determine story points, where all the team members get a voice on how many points a story is worth once they have discussed it in detail. This ensures that all points of view are considered (and no one team/member gets the majority say). Particular attention should be paid to make sure that there are no items that don't have story points allocated (missing story points)

11. Story Point Mix

The Sprint should consist of a mix of stories with a large number of story points and those with smaller numbers. For example, if the team can complete 20 story points in a Sprint, they may decide to have work items that have 1 5-point item, and then a mix of 3, 2, and 1-point items. This balanced mix ensures that not all the effort goes into 1 large story (which might slip) and that there are other valuable pieces being delivered at the same time.

12. Workload Distribution Between Teams

A Sprint should include a balanced mix of work between various teams, for example, the front-end versus the back-end teams, to ensure that no one team is getting overloaded, and the workload is distributed evenly.

13. Dependencies & Interactions

Besides story points, the team also should consider any interactions and dependencies. For example, if one story is dependent on another, then the second one should be completed first, even though it might have a lower business priority

Once all the factors have been discussed and considered, the final Sprint Backlog is created. This is the final set of work items that the team collectively has committed that they will deliver in that Sprint. It is important that there is a way to track and rectify issues such as:

Are there any missing story points
Is there a good mix of story points?
Are there any work items that are too large?

After the Sprint is complete, you can do a post-analysis exercise to determine the quality of the estimates:

How long did the work items take to complete versus the estimation?
Are people doing the right estimations? For example, if a 0.5-story point is taking longer than a 1-story point item, this clearly indicates an issue.

Summary

You can also do Sprint over Sprint comparisons to see whether things have been improving or not. Over time, the Dev team should get better at estimating the workload and determining how much they can include in a Sprint. With the right metrics in place to ensure process consistency, and to get early warning indicators, your Sprints can be more successful.

To summarize, the 13 considerations for successful Sprint planning are: