Maybe you recognize the following situation: you are asked to estimate a new project. So you dive into the - often incomplete and unclear - specifications. After trying to understand the specifications and hopefully having a lot of meetings with the customer and end users you create an neat Excel spread sheet with a work breakdown structure, and some formulas and nice estimation figures. You did a great job! Well done!
Next the project starts, and the project team now has the challenge to deliver software meeting up with your estimates. However, a number of issues surface. The project team looks at the specifications and might interpret these differently. Or even worse, they, or the customer, might come up with new requirements. Or just make different assumptions on the complexity of the software to build. Or the technology used is not as straightforward as people assumed - often the software architects. There goes your estimate.
EditChallenges in software estimation
There are a number of challenges when it comes to estimating software development projects that arise from this small anecdote:
- Initial estimates are hard. Making an initial estimate for a project is hard, as requirements are often incomplete, unknown or difficult to grasp.
- Requirements changes. During a project, new requirements come up, requirements change or are even dropped.
- Technology bias. Technology often turns out to be more complex (and sometimes simpler) then vendors and architects make us believe. Implementing software in a service oriented architecture is a good example.
Concluding: estimation is not an simple activity that needs to be executed at the start of a project. It is ongoing business. Not only do we need to make a plausible initial estimate of the project, just to start the work. New estimates need to be made when changes to requirements, complexity or technology surface. Why? Well simply because these changes will effect the project planning. It's better to be aware of such effects as soon as possible.
EditVersatile software estimation
Therefore, the techniques used to estimate the complexity for software development projects need to be versatile. Think of:
- Transparent. Creating an estimate should be dependent on some high-brow certified expert, but should rather be a team effort, accessible to all team members.
- Swift. If creating an (improved) estimate takes a week, or even several days, it is unlikely that new estimates will be set up during a running projects. There just isn't the time to do so. Hence, your project will not benefit from new insights. However, if re-estimation only takes an hour, or a few hours, it is not unlikely that this becomes a natural step in your iteration, e.g. at iteration start or end.
- Repeatable. Two different estimates for the same project should be equally sized. That is, they don't have to be equal, but they will have to be in the same range.
- Unbiased. Estimates made by people with different levels of expertise, or different technological backgrounds should not differ too much. Estimates must be unbiased. It is therefore of great importance to use an abstract scale to estimate complexity, rather than estimate effort in hours (or even ideal working days).
Smart estimation is the technique where the complexity of software development projects is estimated based on smart use cases. Smart estimation uses an abstract scale (1, 2, 3, 4, 5, 8 and 10), and smart use cases can be stereotyped according to the functionality they execute. The factors above, such as transparency, swiftness and bias can be met using smart estimation.
However, there's one additional technique that makes smart estimation even reliable, swift, but also fun! This technique is called
smart estimation poker.
EditWhat is smart estimation poker?
In agile development games such as estimation poker or planning poker have been around for estimating complexity mainly in Scrum and XP projects. These serious games include customer and project team participation. They attempt to highlight the uncertainty in predictions while offering a meaningful estimation with minimal (or just the right amount of) time spent. Hence, these games match
most of the criteria mentioned above.
However, both variations on the same theme estimate individual work items to a scale that is expressed in hours, or ideal working days. This is not totally unbiased. We tend to use smart use cases as the unit or work, but also as the unit of estimation in projects. Moreover, smart estimation presents us an abstract scale that delivers a much lower level of bias then is expected from estimating the time it takes to deliver individual work items, especially when these are unstructured (unlike smart use cases). The game of smart estimation poker is similar to planning poker, but leverages the use of smart use cases and the accompanying abstract scale and stereotypes.
 Smart estimation poker (each card represents a number from the scale) |
EditWhy should you play Estimation Poker?
It speeds up the estimation process
It is a fact that the longer the estimate is the more uncertainty it contains. So speedup the the estimation by taking a short time to give an estimation. During the Estimation Poker game you can use an egg timer to ensure that discussion is structured.
It avoids 'coloring' of the estimates by a few members
Because of the involvement of the whole team the estimation won't be the estimation of 1 or 2 members, but it will be an team estimation.
It shares knowledge and insights
The biggest advantage is the efficient way of sharing knowledge and insight. The Estimation Poker game activates the team discussions which will share knowledge without getting it too much detail.
It ensures everybody partitions in the estimation
All the members of the team should be involved in the estimation poker game.
It is fun!
EditHow does it work?
The Estimation Poker is really simple to play:
- Participants in planning poker include all of the developers on the team. Remember that developers refers to all programmers, testers, database engineers, analysts, user interaction designers, and so on. In agile teams a team won't be bigger than 10 persons.
- Assign one of the participants the moderator role. Usually this is the customer or an analyst.
- At the start of planning poker, each estimator is given a deck of cards. Each card has written on it one of the valid estimates. Each estimator may, for example, be given a deck of cards that reads 1, 2, 4, 5, 5, 8 and 10 (Smart Complexities). The cards should be prepared prior to the planning poker meeting, and the numbers should be large enough to see across a table. Cards can be saved and used for the next planning poker session.
- The game is played for each Unit of Work. In the Smart Lifecyle we are using Smart Use Cases. Scrum uses (or scenario or user story or..)
- For each smart use case, user story, scenario or theme to be estimated, a moderator reads the description. The moderator is usually the product owner or an analyst. However, the moderator can be anyone, as there is no special privilege associated with the role. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. The product owner answers any questions that the estimators have. However, everyone should remember that at some point additional discussion does not lead to improved accuracy.
- The goal in planning poker is not to derive an estimate that will withstand all future scrutiny. Rather, the goal is to be somewhere well on the left of the effort line, where a valuable estimate can be arrived at cheaply.
- Possibly a summary of the discussion is recorded by the Project Manager.
- The moderator who will not play chairs the meeting, supported and advised by the Project Manager.
- After all questions are answered, each estimator privately selects a card representing his or her estimate. Cards are not shown until each estimator has made a selection.
- At that time, all cards are simultaneously turned over and shown so that all participants can see each estimate.
- It is very likely at this point that the estimates will differ significantly. This is actually good news. If estimates differ, the high and low estimators explain their estimates. It’s important that this does not come across as attacking those estimators. Instead, you want to learn what they were thinking about.
- People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.
- Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the "consensus vote", although the Moderator can negotiate the consensus.
- An egg timer is used to ensure that discussion is structured; the Moderator or the Project Manager may at any point turn over the egg timer and when it runs out all discussion must cease and round of poker is played. The structure in the conversation is re-introduced by the soap boxes.
EditTips
- Don't repeat the estimation process until everybody has the same estimate. Stop the estimation of the scenario when no consensus is archieved in 3 rounds
- Consider time boxing the debate period. The goal is that the technique be simple and lightweight
- The technique works best with three to five participants representing architecture, development, testing, and deployment.
- Work from a list that has already been sorted by business value, and avoid focusing on business value during the work queue priority ordering.
EditReferences
Mike Cohn, Agile Estimating and Planning, Prentice Hall
PTR, Upper Saddle River, NJ, 2005.
Read Chapter 6: Techniques for Estimating online.
J. W. Grenning, Planning Poker, 2002, http://www.objectmentor.com/resources/articles/PlanningPoker.zip.