Just in time, Just Enough Sprint planning

Sprint plannings in Scrum sometimes take long; even when you have all the Stories ready for sprint and estimated. Reason being the team still need to break down stories to tasks, and the Scrum master needs to calculate the capacity and compare the total hours of broken down tasks to the capacity available in order to find out whether the team are committing well, under committing or over committing in order to further negotiate the commitment with the Product Owner if required.

These are basics and widely accepted, but does it make sense to make the team to break down all the stories right at the beginning of the Sprint – during the planning? Most of the time, this breakdown takes a long time, and the longer it goes on, the more the team members get tired and the probability of missed tasks and wrong estimations increases.

On top of that, when the team have all their Stories broken down, sometimes put up on the board, it is easy for software, quality or user interface engineers, that make up the team to pick any tasks from the board, rather than focusing on getting Stories done one by one. By Done I mean Stories meet the “definition of done”. The risks are of course not correctly estimated commitment that may result in sprint failures, failed releases.

So what’s the alternative? The Alternative is using the Just-In-Time, Just Enough approach by doing the following:

  1. First, the team need to understand which stories are important to start at the beginning of the sprint. This is not straightforward and needs some musing involving the team. Part of the importance comes from the priorities set out by the product owner; the other part depends on the resource planning during the sprint.
  2. Once these stories are identified the team proceeds breaking down these Stories to tasks, and stops when they have around 2-3 stories broken down.
  3. Using the data from the already broken down stories, the Scrum Master calculates the predicted size of the initial commitment.
  • Calculating the total hours of tasks broken down
  • Dividing by the total sum of Complexity estimates of these stories
  • Finding the “Average hours per Story Point” coefficient
  • Multiply that by the Total Complexity points of the Stories in Initial commitment

Let me show you this on an example:

Say the team wants to commit to 10 stories estimated all together to 36 Story Points:

User Story 1 – 3 pts
User Story 2 – 5 pts
User Story 3 – 3 pts
User Story 4 – 1 pts
User Story 5 – 2 pts
User Story 6  - 8 pts
User Story 7  - 1 pts
User Story 8  - 5 pts
User Story 9 – 5 pts
User Story 10  - 3 pts
Total 36 pts

Instead of breaking down all that stories into tasks before confirming the commitment during Sprint Planning the team chooses to break down Stories 1, 6 and 9.

Story 1 is broken down to 14 hours worth of tasks

Story 6 is broken down to 28 hours worth of tasks

Story 9 is broken down to 17 hours worth of tasks

Based on that we have the rough Average Hours per Story point ratio of about 3.7

We multiply that by 36 and get 133 hours, which is the forecasted volume of the commitment.

The team and the Scrum Master then see how it compares to their available effective capacity and based on their findings either confirm the commitment or renegotiate.

Now, there are tools like Agilo that do this for you automatically, but if you’re using and Agile tool that doesn’t support this you can always do this manually. This is usually very quick, helps the team to avoid the burdensome full Stories to task breakdown, reduces the WIP (Work in progress) by helping the team to focus on what’s important every step of the sprint way!

This entry was posted in Agile, Definition of Done, Lean, SCRUM, User Story, sprint planning and tagged , , , , , , . Bookmark the permalink.

4 Responses to Just in time, Just Enough Sprint planning

  1. Pingback: Narek Alaverdyan

  2. Craig Girvan says:

    I totally agree about what you are saying here Narak. Sprint planning does take time, and the intensity of this meeting often leaves the team fatigued. And fatigue is likely to lead to mistakes. There are a number of ways that we have tackled this problem at HeadForwards:

    - limit the number of planned stories (a bit kanban-like) at any point in time.
    - alternatively, plan to have a mid-sprint planning session for lower priority stories

    I suppose it depends on how intense and long your sprint planning sessions are, and on whether the Scrum team is truly self-organised. At HeadForwards we track capacity as well as remaining hours over the duration of the sprint and we have no managers breathing down our necks when the capacity curve is well above the commitment.

    Thanks for sharing,

  3. Narek Alaverdyan says:

    Thanks for the comment Craig,

    That’s very much in line with what I’m saying in the post, start with the most critical stories, then as the Sprint progresses get the team together again, maybe a even a few times for 10-15 minutes to break down the stories further.

    This has the following benefits:
    – ensuring the team is focused on the most important stories of the moment
    – getting all team members involved in Story breakdowns throughout the sprint, thus helping the knowledge to be shared


  4. Pingback: Narek Alaverdyan

Leave a Reply

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


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>