Should Teams set a Target Scope during Sprint Planning?

As you are aware by now, the Sprint Planning meeting helps the team identify the backlog of user stories they are going to work on during the Sprint or Iteration. Ideally, the team would review the top priority user stories and choose the stories they are confident about finishing within the Sprint. So far so good, right?

But, every team has a different approach towards capacity usage during a sprint. Depending on the team size and the number of days in a Sprint, there is only so much work a team can do during a single Iteration. Some teams usually are very conservative and take only take enough stories to give themselves sufficient buffer time for emerging needs or experimentation. Some other teams prefer to fill up their backlog to the maximize the teams utilization while some others prefer to have Target Scope in a Sprint. In this article we are going to understand about these different approaches…

Is there a Best or Recommended Approach?

Scrum is not a hard & fast framework of sorts like PMI where every project is expected to function a certain way. Scrum is more of an evolving approach where the team have flexibility to adjust their workings to best suit the project needs.

So, No, there is no such thing as this is the best approach. Each approach as its own Pros and Cons and it is up to you as the Scrum Master to discuss with your team to identify the best way forward for your team. I personally prefer the approach with Target Scope which you will find out more in this article.

Option 1: The Conservative Planning Approach

This is the option where the team only take so many stories so that, they will have sufficient time to experiment on new things or to account for unexpected/emerging needs on the stories chosen for the Sprint.

The Team have very little pressure as they have taken only enough stories they can finish comfortably so this option usually gets the vote from many of the members of the team. On the flipside, the team isn’t continuously improving themselves and are content at finishing a small chunk of work which may not align with the organizational goals or expectations. Team Productivity is usually a flat line and doesn't go upwards.

Option 2: The Capacity Maximizing Approach

This is the option where the team try to take up as many stories as possible and try to provide detailed estimates during the meeting to evaluate whether the team have any surplus capacity available if so, more stories will be taken up.

The Team will be under constant pressure to meet their commitments because there is very little buffer and if some unexpected task/activity comes up, it results in the team not meeting their Sprint Backlog goals. Due to this constant pressure, teams either identify ways to improve themselves and their productivity is an upward sloping line or teams falter under pressure and the productivity becomes a downward sloping line.

Option 3: The Target Scope Approach

This option is a hybrid of the earlier two approaches. You have the committed scope that the team is confident of finishing comfortably. You also add in a few user stories that the team could potentially take up in case their work on the prior batch of stories is completed. Not all stories will have unexpected tasks or need more time than originally planned. So, in most cases the team will be able to take up 1 or 2 extra stories from this Target Scope bucket.

As you can see, this approach doesn't subject the team to the level of stress or delivery pressure like Option 2. At the same time, the team would have a backlog of user stories that they could potentially work on, in case the other stories finish early. This approach gives the team a little bit of flexibility and also the opportunity to deliver more than what was committed which is a good thing isn’t it? Of course, there are some people who usually consider target scope also as a “Must-Finish” type item and push themselves to complete them. Though it might sound like a good idea, a good scrum master needs to help his team understand the meaning of Target Scope and prevent his team from putting undue pressure on themselves which is neither good for them nor for the team.

So, what option do you think is more suitable for your team? Are you someone who prefers the conservative approach or the one with a Target Scope?

Sound off in the comments section.

Scrum Artefacts

In the previous article we covered the different meetings we could have in a Scrum Project. In this article, we are going to look at the various artefacts that are maintained in any scrum project.  

Product Backlog

The product backlog is arguably the most important artefact for the scrum project team. The Product Owner maintains this backlog which contains the prioritized list of product features or functionality that need to implemented with higher priority items on the top. At the beginning of each iteration, the scrum team will pick up the top ranked items and work on them. Some important points about this product backlog include:

• It is a force ranked list of functionality with every item having its own priority
• No two items can have the same priority
• The list is visible for all stakeholders
• Any stakeholder including the scrum team, can add items to this list/backlog
• The product owner maintains the priority of the items in the backlog
• It is updated & refined regularly, preferably in each scrum sprint during the backlog refinement meeting

Product Backlog Item

As we just saw, the product backlog is a prioritized list of items and they are called Product Backlog Items. Each of these items could be individually built, tested and shipped. In most scrum projects, these items are often written as User Stories. Each story has its own detailed requirements as well clearly defined acceptance criteria. The stories are usually sized in such a way that a few members of the team can finish the story within a few days (at max within a single iteration). Some important points about these product backlog items include:

• It specifies the “What” aspect of the feature to be incorporated into the product
• It is usually in a User Story format
• Has specific and clear Acceptance Criteria
• Can be estimated & implemented by the team individually

In some cases, it may not be feasible for the team to build the user story in entirety during a single iteration. Such stories are called “Epic Stories” and are broken down into smaller more manageable sized child stories and each of these children are individually implemented by the scrum team.

Real Life Trivia: A Major point of contention between the scrum team and the product owner is often times the acceptance criteria for a user story. Experienced scrum masters will make sure that when a story is selected for development during a sprint, the story’s acceptance criteria is clearly and unambiguously defined. Some people also call this as the “Definition of Done” which the team needs to accomplish to say that the story development is completed. 

The Sprint Backlog

The spring backlog is nothing but the product backlog items that are shortlisted from the overall product backlog as the potential items for inclusion in the current sprint. This list is identified as part of the Sprint Planning meeting during the beginning of the Sprint. The Scrum team commits to a certain scope at the start of the sprint and focuses on getting them completed during the Sprint. These committed backlog items are usually categorized into 3 major groups – Tasks Not Started, Tasks In Progress and Tasks Completed. A sample backlog chart would look as below:

Some important points about the Sprint Backlog include:

• The backlog is decided based on the commitment by the scrum team and is often times negotiated to achieve certain business objectives as envisioned by the product owner
• The backlog does not change during the sprint execution
• If additional tasks are identified by the scrum team during sprint execution to meet the scope committed during the sprint, they will be added to the list
• The list is used as reference during the daily scrum/stand up meetings
• The list is transparent and visible to all team members

Some scrum teams use electronic tools to represent this sprint backlog while many scrum teams prefer the old school approach where team members put up sticky notes on a white board.

Real Life Trivia: In the “Ideal” scrum world, there is no such thing as a commitment from the team with regards to what will be delivered in a Sprint/Iteration. The team will make a best effort attempt at delivering the user stories identified as part of the sprint backlog and if they are unable to do so (for whatever reasons they may be) the unfinished go back to the backlog and may be prioritized again for continuation in the next Sprint. However, in “Real life” projects, we don’t have this luxury. As we are working toward a product goal (which invariably would have a client impact) the team is expected to keep their commitment for the Sprint and deliver the functionality that was planned during the iteration planning meeting.

Sprint Task

Once we have the committed backlog for a particular sprint, the team will start breaking down the backlog items into more granular tasks. The tasks will address the “How” part of achieving the “What” mentioned in the Product Backlog Item. Each of these tasks is typically 1 or 2 days’ worth of work and each PBI could have more than one team member working on their tasks collaboratively to achieve the PBI’s acceptance criteria. Some important points about the Sprint Tasks include:

• Each task would require a few days of work (Ideal recommendation is at max 1 or 2 days)
• The remaining effort is re-estimated daily for all tasks during the daily stand up
• Usually one member of the team will be primarily responsible for each of the tasks
• A single backlog item could require multiple sprint tasks like analysis, design, implementation, deployment, testing etc. They are all taken up during the same sprint by one or more members of the team collectively.

Sprint Burndown Chart

The Sprint Burndown Chart as the name suggests shows us the work progression by the team wherein we start off with the 100% pending work to be completed on Day 1 of the sprint and work our way towards 0% pending work on the last day of the sprint. Every day during the daily scrum/stand up meeting, the team will share updates regarding the completion of tasks and collectively the team works towards finishing all of the planned backlog items for a sprint by the end of the sprint. That is why it is called a “Burn Down” chart where we target to hit 0% pending work before the end of the sprint. A sample Burndown chart would look as follows: 

While the “X” axis is straight forward and has the dates for the iteration, you may be wondering what the numbers on the “Y” Axis of this chart represent. They represent the amount of work left.

Real Life Trivia: You might be wondering why does the burn down chart go up instead of down during the initial days of the sprint. That is because, when a sprint starts, during the first few days the team is still in discovery mode finding out more work items which would eventually need to be finished for the backlog item to be marked as “Completed”. Hence the small spike during the first few days and the gradual progression towards 0 as tasks gets completed one by one.

Some important points about Burn Down charts include:

• On a daily basis, this chart can show us the total work that still remains (in hours or days – depends on the teams preference) for a particular sprint
• The chart is updated daily and tasks are also re-estimated daily to ensure the chart is an accurate representation of the pending work
• It helps the team self-organize and focus on pending items

Real Life Trivia: In many organizations that have recently adopted scrum practices, the burn down chart becomes more of a management reporting tool rather than a tool to facilitate self-organization within the team. In such a case, this becomes more of an impediment to the team because people with authority over the team are constantly monitoring the progress and the teams efficiency could come down as a result of this constant supervision. In such cases, the Scrum Master should take the initiative to discontinue use of the burn down chart and allow the team to work without such distractions.

In some organizations, apart from the sprint burndown, they also track something called as a Release Burndown chart where they track the completion of product backlog items over the course of multiple sprints. As with any product, the product backlog grows constantly and it is very rare for this burn down chart to hit 0% pending stories because companies constantly enhance their products and it is more of a matter of priority where low priority enhancements will stay in the backlog and get replaced by higher priority enhancements.  Usually Scrum Teams will use the term called “Story Point” while estimating user stories as well as tracking completion. For a release level burn down the number on the Y axis could be Story Points left while for Sprints the Y axis could represent maybe Days or even a more granular measurement factor. People who are very fond of the Waterfall methodology (or are unable to forget it) may choose to have a burn down that represents pending work in Man Days even for Releases.

On a related note, In scrum projects the scrum master captures a metric called “Velocity” which signifies the number of story points of work completed by the team in each iteration. The average velocity of the previous iterations could be a decent yardstick for the management team to predict the potential number of sprints the team may need to finish the remaining items in the overall product backlog. Don’t worry, you will learn more about Velocity and Estimation very soon.