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.


At our download page you find the Cost Estimation Spreadsheet.


  1. Thank you for sharing such a nice and interesting blog with us. Hope it might be much useful for us. keep on updating...!!
    seo company in india
    digital marketing company in india
    seo company in chennai
    digital marketing company in chennai

  2. I read this content really awesome.You provided another one great article.I hope this information may change my business carrier.I can remember these things whenever taking the decision.

    Digital Marketing Company in India

  3. Well Written and Structured Blog. Totally a fan of your writing, I found this blog unique and i have been going through the posts in your blog. Happy Independence Day Quotes For Facebook Status 2018

  4. Wow it is really wonderful and awesome thus it is very much useful for me to understand many concepts and helped me a lot. it is really explainable very well and i got more information from your blog. Satta Matka

  5. Leader in developing embedded system projects, providing Engineering and SCADA solutions using Raspberry pi, Arduino and more.... self driving cars

  6. Your article has piqued plenty of sure assimilation. i'm able to see why past you've got ended this kind of to your liking activity of creating it attractive. Daftar Poker Indonesia

  7. This will open a window containing the HTML source code of the page. Inspect an HTML Element: Right-click on an element basic HTML CODE

  8. Your article has piqued plenty of sure assimilation. i'm able to see why past you've got ended this kind of to your liking activity of creating it attractive. 먹튀검증 안전놀이터 스포츠중계 꽁머니 먹튀검증 토토사이트 안전놀이터 꽁머니