Menu

Friday, November 15, 2013

Estimation Game (2)

The Round Trip Version

This is part 2 of 2 of a post on early estimation in Agile projects. To this end we introduce the Estimation Game. The first part of this post described the Basic Version of the Estimation Game.

In order to leverage experiences from past
projects, it may be a good idea to involve not only the relative measures of “Small”,
“Medium” and “Large” but to relate them to ‘round trips’ from the user to the
system and back to the user. Suppose you have a user and a system with a screen
on which the actor can interact with the system. A round trip then starts with
a stimulus from the user, he performs some action which is input for the
system. The system processes the input and returns the result to the actor. A
new round trip starts when the user reacts to the result, which in turn is a
new stimulus for the system.

The concept of a round trip initially came
from the use case points analysis and was called a use case transaction, but
you can use the concept just as well in estimating stories. Stories may contain
user – system interactions, and if so, you can count the amount of round trips.

Not all stories do contain round trips, for
they might not involve user interaction. Such cases continue to be estimated
relative to other stories on other criteria (as in the first version of the
estimation game). They might also be much more complex than the amount of user
interaction suggests. In that case it is a good idea to split it up and put the
complex logic or interaction with other systems in a separate story.

The estimation game stays just the same, with
one difference: a “Small” user interface based story counts 1-3 round trips, a
“Medium” one counts 4-7 round trips, and a “Large” one counts 8 or more. The
estimation board now looks like figure 69.

Figure 69: Estimation Board in round trip version

Participants have to think of the story they estimate in terms of the number of round trips involved. This often gives an interesting perspective, for the more user(-friendly) interaction you want, the more round trips you need.

We have seen that people are fairly good at envisioning round trips and sharing their mental pictures of the system in terms of round trips. When later on in the project it turns out that a story is more complex than initially estimated, it is easy to go back to the estimate and explain the difference in terms of the amount of round trips involved – understandable to both stakeholders and team.

An example: In the early estimation session, a job vacancy search interface was regarded as simple; it was expected that the user would select search criteria from a couple of drop down menus and then fire his selection. Later on, however, it became obvious that the usability of the application would be enhanced if the system could already react to partial selections and update a counter showing the number of job vacancies found for the current search criteria. In other words, what was regarded to be one round trip turned out to be two. So, it first looked like:

But then it was expanded
as follows:

You see the two round trips clearly here. Both stakeholders and team agreed that the initial estimate should therefore be adjusted.

From round trips to hours

Once you have your user interface based stories estimated on the basis of the number of round trips and others estimated relative to these stories, it is possible to calculate hours. This can be done with the Use Case Points Analysis, which despite its name, can be used for other types of stories just as well.
In the Use Case Points Analysis, the number and weight of the stories identified is the most important component in the calculation of the size of a system. You can balance this size by bringing in a consideration of the system’s technical properties. The size of the system is the starting point for calculating the effort. Effort is balanced by considering the team’s qualifications and other environmental influences.

This may sound a little complicated, but once you fill in the spreadsheet which accompanies the method, you will see that it is in fact quite straightforward. A “Small” story amounts to 5 Use Case Points, a “Medium” to 10, and a “Large” one to 15. We have experienced that 20 Hours per Use Case Point is a good average.
The estimate obtained in this way is statistical information. On average, a story of the same weight will take the same effort but the actual time spent on each one may vary widely. Also in another sense an estimate in terms of Use Case Points is statistical: it does not work for a small system of, say, 5 stories. It needs at least 20 stories to be reliable. Nevertheless, our experience is that an estimate done in this way is closer to the actual effort spent on a project than an early expert estimate.

Combining Round Trips and Story Points

The goal of the Early Estimation Game is to create an estimate for the whole of the project. Later on in the project, the team uses Planning Poker in order to get a more fine-grained team estimate in Story Points. This will be the team’s basis for measuring the team’s velocity and determining commitment for a Sprint. Figure 70 shows how a cross-check can be made between the early estimate in Use Case Points (5, 10 or 15) based on round trips and the more fine-grained estimate in Story Points (0, ½ , 1, 2, 3, 5, 8…) resulting from Planning Poker. The Story Points can be taken to be a more fine-grained version of the Use Case Points. Now if it turns out in Planning Poker that a story estimate is wildly out of range, you know that your story has more functionality than was initially envisioned and you may need to adjust your release planning.

Figure 70: Early Estimation and Planning Poker

Why is it useful to have a mapping between Story Points and round trips?

Round trips help the team to maintain a shared understanding of the measure and share this measure with new team members;

An estimate in Story Points is team bound, whereas an estimate in round trips can easily be shared across teams within an organization;

When under pressure, the team feels the urge to increase estimates which will increase the velocity without the teams productivity increasing. The mapping will show this more easily;

In retaining the round trips approach alongside the Story Points, it is quite simple to keep the Subject Matter Experts involved.