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
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
- 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
- Pineapple upside down cake
- 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
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: firstname.lastname@example.org
Or if you want a more accurate estimate, you need the person/people who are going to be doing the work make the estimate rather than team consensus.ReplyDelete
An analyst prepares some ideas for a project’s features and then schedules a meeting (Feature Blitz) where all the development team [domain expert(s), programmer, code reviewer, SQA engineer, the analyst, and any manager that really wanted to attend] decide the features needed, their specs, their implementation, the proposed order they will be coded and list of dependencies, breaks them into iteration-sized mini-projects, and at the end of the meeting assigns people to each of the above roles for each mini-project. The specs are the notes and digital photos from this meeting. Next each member of the team enters estimates of hours for them to finish their role’s work for each iteration or mini-project. The managers, in Iteration Planning, then swap around any resources or mini-project to maximize the use of everyone’s time, keeping in mind that changes may require the new team member to meet with the analyst or others to get up-to-speed on what happened at the Feature Blitz and that the new team member may not be able to do the role’s work as fast as the one who helped decide the particular implementation in the Feature Blitz. Next there is a commitment meeting where the development team (the four roles besides domain expert) commits to their deadlines even if they have to do overtime, which rarely happened because people became good at estimating their work ability. Simultaneously during an iteration, the analyst writes the User’s Guide, the QA engineer wrote a test suite with corner cases and exceptions that programming may not have thought about, the programmer and code reviewer discuss the details of the implementation and do the coding. Obstacles and progress were discussed frequently among the whole team and communicated to management and other stakeholders. QA tested each code drop so a programming path that wasn’t going to work was caught quickly and little code had to be thrown out. QA had enough time to do their job properly and checked how the feature functioned with other features. Analysts, QA, programmers, and domain experts generated other enhancement ideas not only for the project, but for other projects as there was more time for exploratory testing, prototyping, and thinking about the entire product/program. At the end of the iteration, the released product was more closely bug-free than the waterfall methodology. Lastly, QA had test suites that could be assigned in the future to other QA members or customer support for re-testing prior to each product/program release.
Not only did we use this for estimating a single story, but we did an estimate on the entire product, [Cardiology software that was a patient record, drug-drug interaction, prescription sender, billing, ECG and other device integration, etc., etc., that is, a big product]. We did not do any planning poker game or variation ever, but had ACCURATE estimates by using the Feature Blitz as our method, meaning the one who was going to program the feature gave their estimate after domain experts and others (QA & Analysts) all mentioned ramifications of the code changes.
In two and a half years (including when we first started our scrum-agile-lean hybrid), we were only later than “a single day” on one sprint and less than a day late on three sprints (once was due to hardware load testing that uncovered a need for a hardware change). All other sprints were fully completed on time, with most sprints having work from the subsequent sprint started. (Our sprints were 2 weeks.)
Richard, I am glad that you found an approach that worked for your project.ReplyDelete
This comment has been removed by a blog administrator.ReplyDelete