Agile and Scrum Estimating
When planning the development of a product we need to know how many features will be completed, when will we be finished, and how much will this cost.
NOTE: In agile the normal use is of Timeboxes which are a fixed duration element of up to 4 weeks. The team selects a number of features/user stories from the Product Backlog to be carried out. In Scrum (a method within agile), such timeboxes are called Sprints.
To answer these questions, we need to estimate the size of what we’re building and measure the velocity alright at which we can get work done. From this, we can derive the likely product development duration and its cost by dividing the estimated size of a set of features by the team’s velocity.
Suppose that the product backlog below shows the next release from feature A through to feature XY. To estimate the size of release 1 we add the individual size estimates given in this example, equal to 200 points.
Now we know the approximate size of the release we must calculate our velocity which is how much work the team typically gets done each Sprint.
Estimating Velocity
To do this we simply add the size estimates of every item that was completed during the Sprint. If an item is not done, it does not count towards velocity. So, the sum of the sizes of all the completed product backlog items in a Sprint is the team’s velocity for that Sprint.
Since velocity is the amount of work completed in each Sprint, it is measured by adding the sizes of the Completed Product Backlog items (PBI).
Velocity measures output (the size of what was delivered). However, completing a PBI Off size 8 does not necessarily deliver more of business value than completing a PBI of size 3. It is possible that the PBI of size 3 is high value and low cost, therefore we work on it early, while the converse is true for the PBI of size 8.
In the diagram below, the graph shows the team’s velocity for the prior 7 sprints – note that the average velocity is 20. Now we can calculate the duration by simply dividing the size of the velocity. If the size of release one is 200 points and the team can, on average, complete 20 points of work each Sprint, it will take the team 10 sprints to complete release one.
For planning purposes, velocity is most useful when expressed as a range and this is also helpful in communicating our uncertainty. So, in the example above, we would use the average velocity. As a given team complete each Sprint a history of actual velocities will build up and we could use averages or other statistics to extract a velocity range.
It is important that estimates should be done as a team so that the people who will do the work collectively provide the estimates. And these estimates should be I realistic measure of how big something is, we do not want them artificially inflated due to external influences.
Such estimates should be accurate without being overly precise as generating wrong, overly precise estimates is wasteful and we deceive ourselves by thinking we understand something that we don’t.
We should therefore invest enough effort to get a good enough roughly right estimate
One of the most popular techniques used in agile environments is to estimate the work to be done using a points system. The reason for this technique is to start estimating by using relative estimates not actual estimates and do this by harnessing the knowledge of the whole team so that everyone can contribute.
The most common form of relative estimation is done by giving requirements or user stories a points value that means something relative to another requirement or user story. The use of a points value does not tell you how long each task will take but rather the work effort to complete the task.
We should therefore estimate the product backlog items using relative size is not absolute sizes.
Planning Poker
Creating these relative estimates which are carried out as a team can be done via a technique called planning poker. Here, each team member simultaneously gives their opinion by using three numbered cards showing their chosen points value.
When everyone reveals their points and estimates it is important that any differences, small and large, are discussed and the reasoning behind the differences is understood. Then another round of voting takes place which leads to the team estimates converging towards a collectively agreed points value.
Ultimately, the team can work out how many points they can do in a time box and can forecast future work throughput.
There are many variations of numbering systems used and most are based on the Fibonacci sequence of 1, 2, 3,5, 8, 13, 20, 40, and 100. So for example, I requirement estimated at eight points would involve four times the work effort compared with a requirement estimated as being worth 2 points.
T-shirt Sizing
Another estimating technique is called “T-shirt sizing”. Here, each requirement or user story is classified as either being small (S), medium (M), large (L), or extra-large (XL) and so on.
Size Ratio
S 1
M 2
L 4
XL 8
XXL 16
These systems are deliberately abstract so they can be carried out without any relative values or ratios. The reason why the numbers increase exponentially, and not in a linear manner, is because there is more uncertainty as the size of a task increases.
It is a good idea if the team can agree on a single base story that represents a value of 1 (or another number if preferred), so that when starting the estimation exercise every other story has something relative to refer to from the start.
Further investigation is likely to be required if a story is estimated at a very large number (for example 40 or 100), as this would normally indicate that not enough is known about the story to provide a realistic estimate.
Compare your relative estimates with the relative estimates of other teams since each team has its own individual way of doing this and the approach may not be the same across each team.
Planning Poker
Planning poker is a consensus-based technique for estimating effort. Knowledgeable people (the experts) discuss to expose assumptions, acquire a shared understanding, and the size of the product backlog item.
Planning poker yields relative size estimates by accurately grouping together items of similar size, this also helps the team to establish product backlog item estimation history to more easily estimate the next set of product backlog items.
The full scrum team participates when performing planning poker. During the session, the product owner presents, describes and clarifies the product backlog items.
Each development team member is provided with a set of planning poker cards, so that each estimator can privately select a card representing his or her estimate.
Master Agile Project Management
5.0
Become an Agile Project Management Practitioner!
You will learn the Agile Methodology with our 27 HD video lessons, focused on making you an Agile Project Manager. The classes includes Handbooks, Exercises, and sample exercises – without the need to attend ANY classroom training.
The Projex Academy
related posts: