Should the team set a Target Scope during Sprint Planning Meeting?

Should the team set a Target Scope during Sprint Planning Meeting?

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?


Leave a Reply

Your email address will not be published. Required fields are marked *

ten + 1 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.