Software products deliver value in a multitude of ways, but a universal negative is the effect of time upon the delivery of that value. Many products go to market with unfinished additions, changes, and parts thus tossing out any fixed deadlines, and so often delivery moves through time with only the restraints of budget and resources.
Juxtaposed against this loose way of viewing time and delivery, the most obvious approach to measuring stages of development, or even a feature, is, of course by time. Eventually, you can’t get rid of defining how long your work will take - a day, a month, or a year. It is also clear that many more factors influence development. Anything developed will have a measure of complexity, and specifically, software will take a view of the technological and process perspectives. Besides the development itself, there are other considerations needed to reach completion, such as testing, deployment, documentation, and so on.
When you develop software using Agile, it can be hard to properly timebox every activity in a precise way. There can be many unknowns and plans will change, so planning time to any exactitude can, and it should be assumed will, easily go wrong.
Thus, a unit of measure was created, which we call a “story point”. This “inexact science” addresses the need to measure the effort across time and account for the uncertainties and complexities inherent in the work.
What are these story points?
Before we examine the story point, let us first understand a bigger measurement of the work of development, the “user story”. This is the name given to the work In software development and product management, which is an informal, natural language description of features of a software system (or product backlog item) used in many agile frameworks. The level of breaking the work into more palatable pieces then can be seen as the user story which is then assigned the measurement of story points.
A “story point” is a more abstract value to size a work item than a day, for example. It takes into account all those other factors as well as time to develop a working outcome. Among all of the possible measurements, time doesn’t play a leading role in sizing a story point.
Since a story point is more abstract than a more traditional “man-day” or “hour” of work, it can lead to some confusion when adopting these as sizing units, and some team members may dislike this approach when they start learning it. However, when they use it more and understand the idea behind it, it becomes a more accepted way of thinking about their work. It becomes less science and more feeling for the work, like a painter making a work of art; it is more than just time.
So let’s define 1 story point:
In a cross-functional team, most work items involve multiple or even all team members. For example, a feature could be developed by a front-end and a back-end developer, then tested by a QA engineer, and finally deployed by a DevOps specialist. Then, a minimum feature that involves all facets of activity from the entire team, can be considered as 1 story point.
In this definition both “minimum” and “all types” are important. As an example we can take a feature request like this: display the phone number of a customer in a profile page. Such a feature requires including this information in a page layout and grabbing some data from the database. On top of that, this change should be verified and delivered to the live version of the web application. Every type of specialist in the team should be involved to make this change happen, but it will be quite simple for each of them. Therefore, this amount of work for the entire team can be defined as 1 story point.
As we know, every product and every team is different. Each team should come up with their definition of a single story point to understand it in the same way. Due to this, it isn't a good practice to compare this value across multiple teams, even working on the same product.
When the team has agreed on what a baseline of 1 story point means for them, they are ready to size more complex chunks of work. These chunks just get compared to 1 story point and later with each other to find their value. The whole team discusses every work item, tries to imagine how complex the item could be, and jointly agrees on the sizing.
Now consider a new challenge: if opinions about the size are too close - for example 5 and 6 points - it’s hard to pick the most appropriate one. To avoid this challenge teams often have a bigger gap between possible values. So instead of a linear scale (1, 2, 3, 4, 5…), a scale of Fibonacci sequence is used. In this scale, every next number is a sum of the previous 2 numbers, so it goes like 1, 2, 3, 5, 8, 13, and so on. This way values next to each other are pretty far apart and it’s much easier to categorize the work item with such a distinction.
However, you may wonder how such big gaps in size can be justified. If some work item is bigger than the baseline, for example, 9 or 10 times, how can we be fine with valuing it for 13 points? Aren’t we including a lot of unnecessary extra complexity or time in such sizing?
Thus far there is no mention of any pivotal aspect of this measurement of work. It should not be absolutely precise. It can’t be fully precise most of the time. The size value that we put on every work item is an estimate done by the team with the current knowledge of how complex it would be. It’s one of the big differences between this kind of valuation compared to time. The team can’t promise that it will be accomplished in X hours or Y days. Often, there are many unknowns, especially if you plan your work upfront. But if you estimate the size and complexity of a work item compared to others that you’ve done before, it can be classified much easier, while not bounding it by exact time or set of required steps.
With this in mind, if the complexity of the work grows it makes sense to include more buffer within the estimation. Especially if you are already sure that it will be bigger than another task with a lower amount of points.
How to use story points in planning
The main reason why each work item needs to be sized is to be able to plan its execution within the development process. Once a team starts developing work items, one can quickly note how much work, and how many story points, are getting done within each iteration.
This amount of story points shows the velocity of the team’s delivery. At the end of each iteration, these measurements and their comparisons become the new piece of data, in turn, to be used during the next planning. The long-term goal of the team is to make sure that the velocity is stable, with no drastic changes from one iteration to another, and preferably to reflect an overall growing trend. This shows that the team will have learned how to estimate their story points with high precision and plan their work. It will reflect an increase in their expertise with project solutions.
At the end of each iteration when the team discusses possible improvements to the process, they can also analyze how well they estimated completed work items. Assuming their size to be similar to items completed previously, they should examine if all known information was taken into account during the estimation process, and thereafter do they need any changes in this process. Similar questions can be asked during the estimation itself, such as how current work items compare to other completed work and what should be taken into account with present scoring. This improves each estimation, pulling more precision to the scoring.
Planning estimated work into the iteration
One important rule to follow: make the work fit into one iteration. Generally, the more granularity the team has, the better it can progress on them. Decomposition is the key here.
Imagine the team has 2 backlog items to work on within an iteration. Both are estimated for 21 story points and suddenly some part of one feature can’t be easily completed, so this feature doesn’t get shipped at the end of the iteration. In this view, circa 50% of the effort during this iteration will have been spent without any usable output and value for product users.
Now imagine that the same functionality is being split into 5-6 work items. At the end of the iteration, if a similar problem occurs and the team can’t finish item/s, the delivery will be much more successful, because 80-85% of the value will be delivered to product users.
Summary
Estimating upcoming work by the team in advance gives you more details on how complex it is, whether it needs to be decomposed, and which upcoming iteration it may easily fall into. Since what gets measured gets managed, the regular statistics on team performance help plan each iteration better, identify performance issues, and improve team estimates of new work with more precision.
While story points are provided for short-term, and likely at least in part mid-term planning, you’ll not find it possible to estimate in story points the whole project in the beginning. Thus it isn't useful to plan resource investment in the whole project. In closing, estimation in story points gives a better picture of the mid-term future of product development in terms of delivered value and timelines.
At Jimmy Technologies, we are happy to deliver your development projects. Our value comes from our processes, Jimmy Framework. Developing or helping you through what it means to be Agile with our consultation, our transparent and collaborative way of working through to the fastest savings and/or revenue streams will make the impact you need.
Reach out for more information.
Nikita Lamonov, product owner
