Imagine you work for a restaurant company and the Acquisitions Department has found what they think is a perfect site for their next restaurant. The premises have been purchased and now the place needs to be renovated, fitted-out and opened. But, just how difficult is the whole job going to be, approximately how much will it all cost, and what is a rough timescale to reach completion and your big opening night?
You don’t want to vaguely guess what will happen in the weeks or months ahead since this is ridiculed as simply being ‘guesstimating’. Rather, you want to incorporate a degree of more accurate and substantive forecasting into individual parts of the project, and the project as a whole, in order to achieve the optimum quality result. Similarly, in software development projects such estimates are required and are equally as important. But how can you effectively apply and adapt methods of prediction? In Agile Project Management, the answer lies in scoring your stories.
Clarifying the Word “Score” in Agile
“Score”; a seemingly simple, universally identifiable word but with a multitude of both literal and colloquial meanings and in addition, subtle differences. In its raw form, it is understood as achieving something or reaching a result, as in soccer when a goal is scored or in football when a touchdown is scored. In Agile, this is not quite the case. Perhaps if we used the colloquialism, ‘know the score’, meaning being aware of the essential facts, combined with ‘keep the score’, meaning registering a score as it is made, they would add greater clarity to its interpretation. By using foresight, hindsight and ongoing experiences via a scoring system, less abstract methods of prediction are applied in project management stories. To this purpose, story points are used based on the complexity/difficulty of each story. Note however, that at some stage a link between complexity and the element of time will be required.
Time-Based Point Scoring
Time is obviously the scale the majority of us uses to both look back on and predict most things in life. But think of that age-old adage, “How long is a piece of string?” Yes, of course you want to know how long it will take or roughly take to get your new software completed, ready for shipping and on the market. It’s the same with that new restaurant you might be opening if you worked in the Leisure Industry. Everyone; customers, product owners and investors alike, will naturally be asking; “We want to try it out, when are you opening?” But, a piece of string has infinite length. So, if you think solely about the concept of time-boxes in estimating and scoring stories you risk entering into a very unpredictable domain which will be lacking in quality.
Naturally nonetheless, a Product Owner would almost undoubtedly prefer to score in days rather than in the so-called story points. A definitive timescale feels like a more concrete concept since it provides a reportable estimation of a more understandable deadline particularly where the investors are involved.
However, estimating in the traditional way purely within timescales is a dangerous approach since it cannot encompass external influences. When estimating solely within the parameters of time, there is no built-in consideration for lost working days or other delays for whatever reason they may occur. Similarly, think about a quote from the Ancient Greek orator Antiphon; “Time is not a reality but a concept or a measure” and one can understand that on its own, time is not adequate enough to be used to score stories since in itself it is an abstract devised by Man. Nevertheless, some sort of concept or measure still needs to be applied and here we arrive at story points.
What is a Story Point in Agile
Although still an abstract measure, story points are more virtual or actual. They provide a number which rates the difficulty of a story by being related to the complexities, risks and efforts potentially involved. A story point is assigned to each story based on this but the relative points values between stories is more significant than that of an individual one sitting on its own. A story assigned 2 story points is twice as difficult as one assigned 1 but a quarter as difficult as another assigned 8. Think of that new restaurant again, perhaps a few of the following story point scores would be applied, highest at the top and lowest at the bottom:
34-Dealing with and completing all legal and financial investment matters.
21-Employing and preparing a great management team.
21-Fitting out and decorating the restaurant.
13-Employing and training staff.
8-Building an Advertising campaign.
5-Sourcing local food and drink suppliers.
2-Choosing and purchasing restaurant furniture.
2-Organizing the opening night.
1-Contract clean before opening.
(Total Story Points=107)
For each team working on each part of the project in the different stories, considerations to reach a story point score are based on:
-The amount of work to do.
-Its complexity.
-Its uncertainty.
Unlike the simpler restaurant analogy, the time needed to do it is not so easy to build in within Agile methods. Duration being dependent on the technology and tools, domain knowledge, and the technical expertise of the developers involved. So, although we do need to think in terms of time, and certainly in trying to reduce the time needed to complete as that was one of the original catalysts behind the birth of Agile Methodology, task hours should be part of a separate estimation. In the restaurant scenario, employing and training staff will likely take more time than employing and preparing the management team but it is a less complex and risky process. Hence, the former scores 13 whilst the latter scores 21.
Story Point Scales
What might be thought of by many as a rather non-uniform collection of numbers appeared in the restaurant analogy above so, how are story points actually scaled and scored? Well, most users decide upon one of the following basic mathematical theories to do this, the Fibonacci Scale being the most popular:
- The Fibonacci Scale
1, 1, 2, 3, 5, 8, 13, 21… ie where each number represents the sum of the previous two.
- Tee-Shirt Sizing
XS, S, M, L, XL,….ie where sizes (numbers) increase in single steps.
- Doubling-Up
1, 2, 4, 8, 16,….ie where each number has twice the value of the previous one.
The Fibonacci Scale, or Fibonacci Sequence as it is also called, is preferred because it gives a more natural increase in complexity and a natural distribution curve in estimating. It considers that the bigger a job is, the less precise it can be, whereas Tee-Shirt Sizing or Doubling-Up use simple even-numbered mathematical steps. Such steps can rarely represent reality in development since normally, the bigger a story becomes, the less precise it will be and the Fibonacci Scale recognizes this.
Who Scores the Story Points?
Mathematical theories applied, it is still difficult to implement story points without using a baseline story. Each team working on a story needs to create this starting point which is not necessarily the simplest and smallest but is more likely to be found somewhere in the middle. So, working on the Fibonacci Scale, a 5 or an 8 is more appropriate to be taken as a baseline, namely a user story which is identifiable and understandable by everyone in the team. In the new restaurant analogy, sourcing local food and drinks suppliers scores a 5 and could be used as a baseline for scoring the others. Namely, it would be a story which is not too complex to be understood by all. But, and it’s a big ‘BUT’, always bear in mind; “What is easy for you, may be difficult for me”.
The Role of the Team
- The team members doing the actual piece of work should be the ones deciding upon the estimation in an estimating session.
- Each individual needs to give their realistic estimate of what score it will have so there is an opportunity to discuss differences and then compromise before committing. Most analysts probably agree that this in practice is simply a case of each person writing down their predicted score, 1, 2, 3, etc. on a card and then revealing it to their colleagues. However, besides this planning poker session, other techniques do exist.
- It is better for the team to take two stories together rather than one single task out of context. By doing so, comparisons on the complexity of each are easier to understand.
- If a score is going way too high to match the story’s time boundary, the team should consider breaking up the work into smaller segments.
- To be more accurate in estimating, the team members cannot be pressured by the technical team, product owner or scrum master. They need to be the ones deciding whereas the Product Owner needs the results of estimations in order to prioritize the product roadmap.
Scoring Points for the First Time
Quite obviously, the first time a team tries to apply
Moving On
Story points should be monitored and reviewed each week at least. Do stories need to be allocated different scores because they have become less or more complex? Do we need to break the work down into smaller pieces? In addition, keep a record of how many points are being created and how many of the stories are being completed. Consequently, what becomes apparent is what we can think of as a retrospective ‘final score’ which is named velocity. This is a metric that can be calculated by taking the average total of story points completed over the number of sprints completed. If hypothetically, three identical new restaurants had been opened, based on the scoring depicted previously, the following calculation would be the result: 107+107+107/3=107. Thus, the resulting metric, 107 in this example, can quite comfortably be used in future sprints and estimations. Many agile tools such as Jira Software can be used to track story points and thus methods of reviewing and re-predicting past estimates are currently readily available. Overall, you could say that by learning from history, we are less likely to make the same mistakes in the future.
By scoring your stories you can hopefully take your project planning closer to perfection not ignoring the fact that even with a wealth of experience, estimation for any project remains susceptible to some inaccuracies. But, isn’t it far better that we are logically estimating rather than guesstimating?