TFS as perfect tool for Scrum (Part 3) – Sprint Planning

This is the third part of the series TFS as perfect tool for Scrum. The series is based on my session that I presented at Microsoft TechDays. You can find more introduction in part 1

The agenda for this series is:

1. Introduction in Scrum and TFS

2. Using TFS for grooming your Product Backlog

3. Using TFS in Sprint Planning

4. Using TFS in your Sprint

5. Using TFS in your Sprint Review and Retrospective

Today, Part 3 – Sprint Planning

Part 3 – Sprint Planning

In the previous post we talked about Product Backlog Grooming and what can be done in TFS to do this. This article is about Sprint Planning. In my opinion the most important part of the Scrum cycle. Sprint planning is a great moment to validate the quality of your backlog and therefore gives valuable information about improvement points. Also sprint planning is a real team effort and a great way to get everybody aligned. In short, sprint planning is about selecting the Product Backlog Items (PBI’s) for the sprint, completely understand what is meant by the PBI’s and after that breaking down the PBI’s in tasks and estimate time needed for these tasks.

So, what happens in sprint planning. The meeting consists of 2 parts. In the first part the sprint goal is discussed. The Product Owner (PO) shares his vision of the sprint goal with the team. The appropriate PBI’s (that should be on top of the backlog by now) are selected to meet this sprint goal. The Product Owner then starts reading his stories out loud and emphasizes the acceptance criteria. The team can now have a discussion (short !) to finalize their understanding of the PBI and clear things up by adding notes or acceptance criteria. Everything that is now unclear should be either demystified or the backlog item should be removed from the sprint backlog and be put back on the product backlog for some rework.

During this first part, novice Scrum teams often have a lot of trouble and dive into deep discussions about PBI’s. Most of the time the PBI’s are too big or far too rough, leaving so much room for discussion that sprint planning is mostly about discussing the content instead of understanding and “polishing” the PBI’s. Often it results in too little time left in the timebox for proper split up or estimation of the tasks. This eventually results in a messy sprint and thus a messy increment.

In my previous post I referred to this post of Robert Galen which talks about grooming sessions throughout the sprint about 4 kinds of PBI’s. Use the 10% grooming time and discuss long-term, mid-term and short term PBI’s. This way you can have the content discussion during grooming and not during sprint planning. This other great post also emphasizes the need for this approach and shows a great visualization for the backlog (8 and 9).

When the first part is done (try to make this as short as possible and no longer than 50% of the timebox (8 hours for a 4 week sprint and proportionally less for shorter sprint)) it is time to break down the PBI’s in tasks. Once a PBI has been broken down, estimate hours for each task with the development team. I always recommend to break down a PBI and estimate it directly instead of breaking all PBI’s down and then start estimation all at once. Chances are, that when the timebox is over you have a lot of tasks but no single hour estimated. So do it one by one so you can make sure you end up with some PBI’s (the top ones) you can start working on.

Estimation is a team effort and therefore a team activity. Many teams (including the teams I work with) use Planning Poker to do the estimations. It provides a nice way to have everybody involved in the estimations. As an extra, Planning Poker uses the Fibonacci sequence to estimate. This helps in avoiding endless discussions about small time differences. So Planning Poker serves two important purposes and most important..It is fun !

Team estimations instead of individual estimation

Let me explain this a bit. First of all, estimation with the team is important because everybody shares the responsibility. It is nobody’s fault that a task was wrongfully estimated. And because the team is multi disciplinary changes are you get different points of view. There is also a more scientific reason for this practice. The Delphi method proves that estimations are more reliable with a larger group size. It is nice to scan through this research done by N. Dalkey.

source: http://192.5.14.43/content/dam/rand/pubs/research_memoranda/2005/RM5888.pdf

As said, there is also a second purpose with planning poker. Avoiding too detailed estimations. This is done by using the Fibonacci Sequence. This sequence (0,1,2,3,5,8,13,21,34, etc.) is great to use with your team. Instead of having discussion about minutes (is it 12 or 13 hours, 5 or 5.5 hours) you focus on the larger chunks. In practice it does not really matter if something is 12 or 13 hours. Another item will straighten this out later (take a look at the Law of large Numbers).

Challenges during “sprint planning

So back to our Scrum and TFS combination, what are the challenges we are dealing with in the sprint planning phase, and what can we do in Team Foundation Server to alleviate these challenges.

The challenges that I hear the most are these:

• We have defined our sprint goal but where do we put this?
• How can I select my PBI’s and how can I see if they fit in my sprint?
• How do I distribute my work to a sprint?
• How can I check my capacity?

As said in part 1, Team Foundation Server is just a tool, which does not solve any of the problems, but it contains several very useful features that allow you to define a process that will!

Use Team Foundation Server

Sprint planning is a creative process. When using a computer (to fill TFS) during sprint planning I saw teams behaving differently. The guy behind the keyboard was the one with the power. Other team members were waiting while he typed, or talked (and chuckled) about the typo’s he made instead of focusing on the real purpose of the meeting. Do your sprint planning with sticky notes on a wall and fill in the details after the meeting or let someone outside your development team or the Scrum master fill in the estimated PBI’s to have a direct view on your capacity.

Storing the sprint goal

The first part of the sprint planning meeting, is defining the Sprint Goal and finding the appropriate Backlog Items. In TFS 2010 we had the [Sprint] Work Item type which we could use for storing Sprint dates and other things about the sprint. When TFS 2012 came out, the sprint dates were part of the Iteration tree and the sprint item became obsolete.

I miss the sprint work item. It allowed me to store all kinds of information about the sprint, without using another tool than my favorite one. So what I did, I reintroduced the sprint work item. Sure, I can store my Sprint goal on a SharePoint Dashboard or write it on a whiteboard, but I like to have everything in one place.

I created the sprint work item almost exactly as it was in TFS 2010. Instead of a title, I use the Iteration Tree to have it point to the right sprint, and I added tabs (and HTML fields) for storing the Sprint goal, Sprint Review and Sprint Retrospective. My Sprint Work Item now looks like this.

The definition of the sprint work item can be found in the zip file attached to this post. You can use the witadmin command [importwitd] to import this work item into your own project (http://msdn.microsoft.com/en-us/library/dd312129.aspx).

Selecting PBI’s for your sprint and distribute them

Selecting PBI’s for your sprint is quite easy with TFS. When using the Product Backlog in the Web Access client, you see a sorted list of all the PBI’s with their effort (in storypoints) as a column in this list. By switching on the forecast lines in the Product backlog, lines are drawn underneath the items that fits your sprint.

This is based on the velocity that you type in. Velocity is the number of storypoints your teams closes during a sprint. Normally you take the average of the past sprints and use this number. All PBI’s above the forecast line are a candidate for your sprint.

Once you have a clear view on the PBI’s, just drag them to the appropriate sprint.

More about this great feature you can find on Jason Zander’s blog or on TFS.VisualStudio.Com.

Capacity Planning

When you put the right PBI’s in to your sprint, it is time for splitting them up in tasks. Every PBI is split up in task work items, and the work items are estimated in hours (!!). To have a clear view if the number of hours you estimate are still in line with your capacity, you can use the capacity feature of the TFS Web Access Client. Beware that is a Web Client feature. The capacity cannot be pulled from the warehouse or in a work item query!

By selecting the right sprint, the capacity tab can be used to list your resources and their availability. You can use the activity drop down for some functional capacity planning.

By assigning tasks to the right activity and people, the bars fill up and you get a great view on your capacity planning. When you use sticky notes during sprint planning (as I always advise) you can fill the tasks after every estimation of a PBI to have this view.

More about this, you can find here.

Conclusion

I think sprint planning is the most important ceremony during a sprint. Sprint planning is a great moment to validate the quality of your backlog and therefore gives valuable information about improvement points. Besides that, sprint planning is a real team effort and a great way to get everybody aligned. Team Foundation Server has some great features to support sprint planning but beware of “apathetic” behavior when 1 person sits behind a monitor. Use sticky notes to support the creative process and put them in TFS after this process. E.g. split up a PBI, play planning poker on the tasks, put them in TFS. We can quickly review the challenges that I often hear to see if we addressed it all.

• We have defined our sprint goal but where do we put this?
  • Create a sprint work item to address this. You can also use this sprint work item for review and retrospective input.
• How can I select my PBI’s and how can I see if they fit in my sprint?
  • Use the forecast lines and velocity graphs to get a clear view on what sould fit into a sprint
• How do I distribute my work to a sprint?
  • Use the product backlog view of the Web Access Client to drag items to the appropriate sprint
• How can I check my capacity?
  • Use the capacity features of the Web Access client.

Resources

• Grooming your backlog for success – http://www.batimes.com/robert-galen/grooming-your-agile-backlogs-for-success.htm
• 10 tips for adopting scrum to save your project – http://zenexmachina.wordpress.com/2012/03/30/10-tips-for-adopting-scrum-to-save-your-project/
• The Delphi method – http://en.wikipedia.org/wiki/Delphi_method
• The Delphi Method Research report – http://192.5.14.43/content/dam/rand/pubs/research_memoranda/2005/RM5888.pdf
• Fibonacci Sequence – http://en.wikipedia.org/wiki/Fibonacci_number
• The law of large numbers – http://en.wikipedia.org/wiki/Law_of_large_numbers
• Witadmin reference – http://msdn.microsoft.com/en-us/library/dd312129.aspx
• Velocity explanation – http://msdn.microsoft.com/en-us/library/vstudio/ff731575.aspx
• Jason Zander about Sprint Planning – http://blogs.msdn.com/b/jasonz/archive/2012/05/29/my-favorite-features-managing-projects-with-the-backlog-sprint-planning-and-taskboard-features-in-team-foundation-server-11.aspx
• Using TFS backlog tools – http://tfs.visualstudio.com/en-us/learn/collaborate/manage-your-backlog/
• Plan your sprint – http://tfs.visualstudio.com/en-us/learn/collaborate/plan-your-sprint/

Attached Files: Download Sprint Work Items.zip