Fast Estimation

Imagine you have just completed some Product Discovery work and have a pile of User Stories that need to be estimated. You look at the pile and think, wow that will take hours to estimate using Planning Poker. I just want rough estimates so that we can put together a release plan. We know the plan will change in the future, but we need some starting point. What can I do? 

The answer is Fast Estimation. 

Fast Estimation is derived from Planning Poker. With some preparation and a 1 hour workshop it is common for a team to estimate about 30 User Stories. Teams I have worked with have successfully used it to estimate new functionality, automation of processes, improvements to internal practices and organisational change work.

While estimation is the main objective of the Fast Estimation process, another significant benefit you get for free is Shared Understanding. By this I mean the discussions that occur help to clarify in the minds of the team members what work is required, how it inter-relates and how big the entire backlog is. The knowledge that is gained about the backlog as a whole can often be more valuable then the estimates assigned to individual User Stories.

Fast Estimation Process

Preparation
Write out the User Stories to be estimated onto Index Cards of the same colour. A short cut that often works well is to just write the Title of the User Story on the index card and have the details of the User Story on hand during the session (i.e. in an electronic tool, or a printed spreadsheet, etc).

Find one to five Reference User Stories. These are User Stories that are well understood by the team and will act as a reference point for the upcoming comparative estimation. Ideally the team will have recently completed those User Stories or have at least estimated them in Story Points. The Reference User Stories should have differing Story Points, ideally being in the 2 to 20 range. I recommend at least three reference User Stories and usually aim for five, however you can get away with one. The case where your team is new and does not have any reference User Stories; sounds like a topic for another day. If you are really stuck just pick a User Story that you think is 3 Story Points, and use that for your Reference User Story.

Write out the Reference User Stories onto Index Cards of a different colour to the cards used for the User Stories to be estimated.

Schedule a 1 hour meeting in a room that has a long table, big enough for the team to gather around.

During the workshop
Set the scene for the workshop by explaining the following points

• The objective of the workshop is to roughly estimate this stack of User Stories (show them the stack of Index Cards so that they can see how many there are), this will help to emphasise that time is of the essence. 
• Fast Estimation will only rough estimates for these User Stories. 
• There will be lots of assumptions and hence the estimates will not be very accurate.
• The team will get another chance to re-estimate these User Stories in normal grooming session prior to starting work on the User Stories.

Layout one set up Planning Poker cards on a long conference table in ascending order i.e. 0, 0.5 .. 110, ∞.  It is a good idea to leave more space between the lower / middle numbers as hopefully more of the User Stories will end up there. If there are lots of User Stories at the large end of the scale that is a whole different problem, good luck with that ;).

Place the Reference User Stories below the Planning Poker card that corresponds to its Story Points. As per the picture below.

Picture 1: Planning Poker cards and Reference User Stories, with un-estimated User Stories at the bottom.

Confirm with the participants that they understand the Reference User Stories and agree with the Story Points for each. You may need to adjust one or more of these. Once you progress past this point, do not change the Reference User Story – Story Points any more these are now set in stone.

Divide up the User Stories roughly and hand them out to the participants.

Give the participants a couple of minutes to quickly read their set of User Stories to themselves.

Pick someone at random and ask them to read out their User Story and then place it underneath the Planning Poker card that corresponds to their estimate. Only allow a brief time for this. Ask the group if they are happy with that estimate and discuss/move it as necessary. Encourage participants to move the card if they disagree and to explain their justification at the same time.

Picture 2: First User Story Estimated

Ask the group if there are any similar User Stories in peoples stacks. If so, repeat step 8 for those User Stories. Once there are no more similar User Stories pick another person at random and repeat step 8 for that User Story.

Work your wait through all of the User Stories, placing and discussing, finding similar User Stories, etc. etc.

Once all of the cards are all in position you can quickly write the Story Point estimate on each Index Card and gather them up.

Picture 3: All User Stories estimated 

As a final wrap up to the meeting it is again worth mentioning that the team may need to re-estimate these User Stories using Planning Poker before taking them into a sprint planning meeting.

A variation I have tried that did not work as well
After handing out the index cards, everyone places their cards at once in a big rush of activity. Then the team discusses them and re-estimates them as appropriate. This approach raises the energy in the room but it is a bit more confusing. Individuals will find it confusing to place their cards without the understanding of the backlog that they build up while discussing the User Stories one by one. The benefit to this approach is that very rough estimates are assigned to all of the User Stories up front, so if you run out of time at least you have everything estimated.

Teaching Fast Estimation
I have an example game to teach people Fast Estimation which extends on the fruit estimation of Planning Poker that I learnt in the Certified Scrum Master course taught by Rowan Bunning.

Write out the following Items To Cook on Index Cards, and place ‘B.L.T’ your three Story Point Reference User Story  (I have found that due to the simplicity of these User Stories 1 reference story is enough). 

Ask the participant to estimate cooking these items from scratch. I.e. for Eggs Benedict they are expected to make their own hollandaise sauce. Guide them through the Fast Estimation process,  this game usually takes less then 10 minutes (provided the participants are familiar with Planning Poker and Story Points).

Items to Cook

• Eggs Benedict
• Tin Baked Beans
• Fruit Salad
• B.L.T.
• Crispy skinned Salmon
• Poached Eggs Soufflé
• Cheese Burger
• 64 Cup Cakes
• Garden Salad
• Alacarte, 3 courses for two
• Cheese Cake
• Duck Ala orange
• Caesar Salad
• Alacarte, 3 courses for ten
• Lasagne
• Pineapple upside down cake
• Burrito’s
• Mashed Potato
• Beef Korma
• Banoffee Pie
• Fish & Chips
• 12 Fancy cup cakes

Interested in estimation?

• Story Points are only one third of the reason to estimate
• Story Points do not equate to time
• Top Tips for Planning Poker

Related Reading
I can recommend these blogs for other great approaches to estimating stacks of User Stories:

• Steve Bockman - Team Estimation Game 
• James Grenning - Planning Poker Party 

Training available in South East QLD, Australia

If this article was interesting to you, then your team would likely benefit from face to face training on Agile Estimation. I run a one-hour Agile Estimation training session, that is highly interactive, immensely fun and teaches the foundation of agile estimation along with how to effectively run Planning Poker as well as Fast Estimation. Please contact me to set up a training session for your team: andrewrusling@hotmail.com

Book Review: Presentation Zen - Simple Ideas on Presentation Design and Delivery, by Garr Reynolds

Visually it is a beautiful book that shows off Garr Reynolds design skills.

If you like discussing design and the art behind it, then this book is for you. It does a good job of discussing the design of presentations from an abstract approach, the writing style of his blog Presentation Zen shines through.

However if you want to improve your presentations this book offers very little. The useful information in the book could be condensed to about 20 pages; you may be better off searching the web for articles on basic design principles.

I picked it up hoping to improve my presentations, I walk away knowing about a few more free picture sites, having seen some great examples of slides and learn a few tips. Unfortunately the Zen of presentation design has not passed into my way thinking.

2 stars

Photo by Wesley Fryer

Training Course Review - Passionate Product Ownership

Course Passionate Product Ownership
Presented by Jeff Patton 
Organised by SoftEd 
Held in the Hilton Hotel Brisbane 


Overall: 5 Stars

The venue, room and training materials were all prepared ahead of our arrival. The room was set up for five groups of five people. Each table was stocked with extensive pens, paper, index cards, sticky notes, printed notes, etc. There was also the book ‘Inspired’ by Marty Cagan and a USB drive with over 500Mb of material including slides, cheat sheets, guides, articles, templates, and all of the videos that he showed to us.


The catering was timely, organised and tasty, well done to the Hilton. Eating lunch in the recently refurbished restaurant was pleasant and hassle free. They took our lunch orders at morning tea and served it to us promptly on our arrival at lunch time. The facilities were great however I was not a big fan of the chairs. 


Jeff is an excellent presenter, facilitator and educator. He made it all look so easy to keep a diverse group engaged and focused for two solid days. His extensive knowledge and real world experience in many different contexts shines through as he provides examples and answers questions with ease. Combining all of his skills he was able to keep us on schedule while still addressing the widely varying needs of the audience (different contexts, skills and experience). It was very impressive to see Jeff in action.


There were practically no slides projected, he used spoken word combined with a projection of the drawings and notes that he made in real time. This approach of projecting the web cam of his drawing was very engaging. Jeff made extensive use of games to get us to experience our new knowledge and techniques in action. Towards the end of the course he gave away a copy of ‘Game Storming’ by Dave Gray. A quick flip through this book (one of my colleague one it) told me that Jeff has used plenty of ideas from this book in his course preparation and deliver. It is going onto my must read list.


Discussion regarding Scrum was limited and rightfully so. I have heard of others attending CSPO courses that are practically the same as a CSM course.


The vast majority of the two days was spent on the Discovery Phase, understanding product goals, target outcomes, users, interactions, activities and business prioritisation. There was only a small amount of content and on planning and co-ordination. Jeff is focused on building the right product, which is exactly the focus that a Product Owner should have. 


Overall it was the best course I have ever attended. The change at work has been profound with many of our attendees now using techniques from the course in our day to day work. There are also plans to consider rolling out more of the approaches and techniques with our upcoming releases.


I highly recommend this course for all managers, coaches, scrum masters, business analysts and of course product owners.


Photo by: Kris Anderson

Keeping track of great agile books

Helping others to grow, often has me thinking about which articles, books and presentations I should recommend for them to read. With the vast wealth of materials available regarding agile, Scrum and other methods I find that I some times lose track of the material that is most appropriate for people as they progress along their own agile journey.


A simple free tool that I have found that helps with this issue is Library Thing. 


This site allows me to easily list, rate, tag and categorise all the books that have read or am thinking of reading.  


A quick look at the members who have some of the same books as me revealed a few agile luminaries such as Bas Vodde and J. B. Rainsberger.


I can highly recommend signing up to Library Thing and having a look around.

Full Steam Ahead?

Is the team really working that well, that they have no impediments? I don't think so...

It can take a long time for new teams to feel comfortable to raise their issues and to ask for help.

Christopher Broome from the Scrum Alliance has an excellent post on this subject: I have no impediments.

Picture by:  J. P. Mueller

User Story Centric Stand ups

As a Scrum team learns to work closely together and to focus their efforts they tend to only have a couple of User Stories in progress at any one time. Working collaboratively with limited work in progress brings several benefits, namely increased shared understanding and a reduced risk of partially completing a User Story.

Unfortunately when Scrum Teams work closely together on a couple of User Stories, their Stand Up Meetings become disjointed. By this I mean that as each person answers the three questions, several people will need to speak out of turn to present a full view of what is occurring and what needs to be done.

The standard format for Stand Ups where each team member answers the three questions in turn is a Person Centric approach. The standard format is a great way to teach those new to Scrum what information they are expected to provide, what information they should seek and what planning they should carry out.

However when the Scrum team works closely together on User Stories the Person Centric Stand Up no longer represents how the team is working.

Teams use their task board to visually represent the work they are doing and how they do it. I recommend that Stand Ups should also represent how the team is working. Hence when a team is collaborating closely on their User Stories I recommend the team switches to User Story Centric Stand Ups.

User Story Centric Stand Ups

1. In priority order discuss each User Story

        A. As a team update the work that was done since last stand up.

        B. As a team plan the work for today.

        C. As a team discuss any impediments relating to the User Story.

2. Ask the team if there are any other tasks that have popped up.

3. Ask the team if there are any other impediments. I.e. Impediments not directly relating to a User Story.

4. Ask the team if everyone has a clear plan for what to work on next.

This Stand Up format fits in easily with teams that are used to answering the three questions and have moved onto collaborating around User Stories.

User Story Centric Stand Ups are not recommended for new teams, only for teams that are comfortable with the Person Centric Stand Up and work collaboratively around a couple of User Stories.


Photo by: Kris Anderson

Book review: Kanban, by David J. Anderson

4/5 stars

This book is very easy to read, and focuses on kanban (Japanense visual pull system), and Kanban (Davids Organisational Change Management Strategy).

David does a great job of explaining the theory behind and practical advice on implementing all of the techniques that go with Kanban. His experience with this stuff is throughout the book and these examples help to explain the topics under discussion.

I took a lot of value out the discussion around flow, limiting WIP, bottlenecks, and the history of Kanban.

While I do not think that I would apply Kanban to teams/departments that build large features; I would certainly use it for maintenance/small feature teams. Either way the knowledge around flow, etc is very valuable.

Image: David J. Anderson and Associates