You are here

Agile in Action - Sprint Planning (Part 4 of 5)

July 31, 2015

Sprint planning meetings are held before the start of each sprint and are attended by product owner, scrum master and the entire development team. During the meeting the product owner describes the goal of the upcoming sprint and prioritizes the backlog of user stories based on that goal. The sprint goal is a concise description of what the sprint team plans to achieve in the upcoming sprint. An analogy can be made between the sprint goal and an epic story; the sprint goal is a high level description of what the development team will be working on during the sprint and is not intended to include low level implementation details. The sprint goal summary can be used by the sprint team to communicate what the team is focusing on to stakeholders outside the sprint.

The development team then discusses the prioritized user stories with the product owner, capturing the details needed to implement them. The product owner and the development team typically aim to discuss two sprints worth of stories to ensure that each story that ends up in the sprint backlog has been addressed. Any stories that are covered in this meeting that do not make it to the sprint backlog will remain in the scrum backlog until they are added to a future sprint or removed to account for changing requirements.

Once the backlog of user stories has been prioritized to match the sprint goal the development team works together to estimate the effort required for each user story. User story effort can be estimated several different ways but, at Bloomy, we like a method called Planning Poker. We practice this technique through the software we use to manage our scrum processes, but it can be done by hand just as well—the following paragraph describes the latter.

To start a round of planning poker the scrum master selects a user story from the backlog and reads it to the development team. Each member of the development team then considers the relative amount of effort required to implement the feature and selects one card from a deck of index cards (with values of 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, Infinite) that they believe reflects this effort. It is important to understand that these effort estimates are unitless, meaning that the team is actually estimating a relative amount of effort and not an absolute number of hours. As an example, when we go to the movie theater we order a large popcorn, and not a 48 ounce popcorn; the volume of popcorn that makes up a large may differ between theaters but will always be in the same ballpark.

Once the prioritized user stories have been assigned unitless effort estimations the product owner might reprioritize the backlog. If a user story that the product owner assumed would be easy to implement received a high effort estimate, then the product owner may consider lowering its priority in the interest of getting more stories higher up in the backlog. Likewise, if a story the user manager had assumed to be technically challenging came back with a low estimate, the product owner may consider moving it up the list to ensure that it gets completed in the upcoming sprint.

With the prioritized backlog finalized, the development team selects the top N user stories whose effort estimates sum to the number of points they are typically able to complete in one sprint. If a development team is typically able to complete 400 points, and the top 15 user stories total to 398 points then the team will select those 15 user stories and use them as the sprint backlog. The team then works through these stories to complete the sprint.

If you would like to read parts 1, 2, 3, and 5 of the Agile in Action 5-part series, please visit the following pages:
The Ceremonies (Part 1 of 5)
The Scrum Team (Part 2 of 5)
The User Stories (Part 3 of 5)
After the Sprint (Part 5 of 5)

If you would like to learn more about Bloomy's LabVIEW consulting services please Contact Us via webform or telephone.

Category: Tags:



This is a great article for LabVIEW developers to start with the Agile. :-) But when I started following I have plenty of questions. Pardon me if I'm throwing all questions here. :-D

Do you allow multiple developers to work on the same user story? Or how would you split up a user story which has to be worked by multiple developers? Do you create list of tasks for a user story and assign each task to respective developer? In such case how would you justify the user story points? Would you ensure all developers together should cover the user story in the decided user story points? How do ensure each developer is assigned only the so much work he can do in a sprint? Do you ensure each developer can do max of 20points in a sprint and assign only such number of points to him?

Hi digiajay,

You ask lots of great questions and I will do my best to answer them concisely. If I leave you wanting more, I recommend reading Jeff Sutherland's Scrum Papers.

Now, on to my thoughts!

Do you allow multiple developers to work on the same user story?

Development teams are self-organizing and manage their own development efforts. No manager decides on or assigns work. The developers are allowed to divide and conquer if they want to; if a story can be cleanly divided, one might rightly wonder whether it should have been two stories all along. would you split up a user story...?

This would likely happen during a scrum planning meeting (planning poker). If the development team recognizes a story really contains multiple discrete tasks, they would negotiate and create these tasks in the backlog for further discussion and point estimation.

Do you create lists of tasks for a user story and assign each task...?

No. The development team handles implementation without micromanagement. One goal of planning poker and the other scrum planning ceremonies is to avoid the surprise of hidden and/or nested tasks (i.e. risk). Developers select their own tasks and work together to achieve the sprint goal. The development team estimates points during planning poker and planning poker is mainly a practical, honest, technical discussion among mutually accountable teammates.

How do you ensure each developer is assigned only what he can do in a sprint?

This is not a manager's role--there is no manager. The development team ensures this by honestly and correctly practicing scrum (and the scrum master facilitates that process). The team commits to a sprint only after playing planning poker during which they mutually agree on the difficulty of the stories.

Consider the difference between pushing and pulling. The conventional approach involves pushing work into a developer's work queue and trying to hold him accountable if he doesn't get it done. Scrum lets the developers pull work into their work queue and the team members hold each other accountable. Scrum's existence is proof of which model works better.


I hope you found this helpful. Thanks for reaching out!


We have used JIRA Greehopper (now "JIRA Agile"), ScrumDo, and even some old-fashioned index cards to manage scrum projects.