Correlation of Stories and Story Points

Reference to my post "Correlation of Stories and Story Points" on agilecoach.de.

Done-Related Story Estimation

In today's Backlog Grooming I tried a new method of estimating user stories. The estimations were based on and related to known done-stories of former sprints. The method is very simple and contains only five steps. 

Step 1: Get user stories from Product Owner

Your Product Owner should be prepared for Backlog Grooming and bring his top-priority stories for discussion and estimation.

Step 2: Select reference stories

Pick a few random stories from your already done stories. Make sure their story points differ enough so a typical mixture of story points is in the set. In today's experiment I chose stories with 3, 5, 8, and 20 points.

Then write a new reference story card for each of them in the following way: write the story on the front of the card and write its story points on the back of the card. Make sure to hide the story points from the team's eyes for now.

Step 3: Sort user stories

Let the team find the right order of old reference stories and new undone stories. You will notice much more comparative conversation on the stories than with playing Planning Poker.

Step 4: Show story points

Now the fun part begins. Turn the reference stories and surprise the team by showing the reference story points.

Step 5: Adjust stories and story points

Let the team discuss if any adjustments are necessary. There will be more conversations on single cards to gain more understanding. Some stories may change due to these conversations. Take care that stories with high points get split properly. In today's example the story at the bottom with 20 points could be discussed and split into two stories. The result was much deeper understanding of the real value for both the team and the Product Owner. 

I'm looking forward to the Sprint Planning meeting next Monday.

Book: Mike Cohn - Agile Estimating and Planning

Everyone getting agile has to read this book!

Author: Mike Cohn

Title: Agile Estimating and Planning

http://bit.ly/1JA1Cr

Rating: highly recommended!

This book is just a must have and a must read! Mike Cohn describes all important aspects and concepts of estimating and planning in an agile approach. Lots of real-world examples show how to apply these concepts.

Note that this book is NOT about traditional estimating and planning for agile projects. It is about *agile estimating and planning* and this is what agile projects need to succeed.

You probably read several Scrum books and know the basics about story points, planning poker, story priorities, sprint planning, burndown charts, and velocity. If you really want to get in-depth details on all these and related topics you have to read this book! It is worth every single word - and Mike knows that "every word counts".

If you already are running agile practices then read this book and inspect your methods. You will find so many things to improve and adapt.

Enough said. Buy it, read it, and keep it on your table for reference!

PS: I'm looking forward to read Mike's new book "Succeeding with Agile". It will be on Amazon's stock on Monday.

Planning Joker

In one of our last planning poker sessions the team was asked to give estimates for a story. Surprisingly all of the team members chose either a 100, an infinite card, or a combination of cards to express the weirdness of the story. After some explanations it came clear that we were missing an important card in our deck: the Planning Joker!

What's the meaning of the Planning Joker? - "I will not estimate this story as it is completely crazy."

If a story has a vast lack of meaning and does not contain any useful information then the Planning Joker is the right choice. An example for such a story would be "as a user I want to see all information" - whatever this means, it is not estimatable and needs clarification by the product owner.

Besides of a new meaningful expression in your poker sessions, the Planning Joker adds some healthy amount of fun to these sessions. Try to use it and see if it works for you - feedback is highly appreciated.

Thanks to Anton Morozov for the nice drawing of the Planning Joker.

Iteration planning: hours of tasks or number of tasks?

I recently had a discussion with another Scrum Master. He participated as a chicken in my sprint planning meeting.

When the team had finished the breakdown of user stories into tasks, I wanted to get estimates in working hours for every single tasks of the sprint. The other Scrum Master wondered why I insisted on getting those hours. He would have just worked with the number of tasks in the sprint rather than put more effort in getting those estimates. In his eyes that would be sufficient to track progress and draw an iteration burndown.

In my point of view it is not enough to have the number of tasks solely due to following reasons:

• task sizes are unknown and not comparable
• it is difficult for the team to choose open tasks for the next day without knowing an estimated effort in hours
• it is impossible for the team to honestly commit to a story on the basis of story points (or ideal days) only
• the iteration burndown will get more realistic and shows "real work done"

Finally an iteration contains a more detailed scope than a release so more detailed estimating and planning has to be applied.
Bibliographic recommendation on this topic: Mike Cohn - Agile Estimating and Planning (http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415)