Agile Story Points - Scope and Effort Management

Abstract: Using story points to manage both scope and effort is convenient but not ideal. Story points should be split for scope and effort management. Such separation will ease project analysis, planning, and communication. Features or business values should be the reference for scope story points. Efforts should be tracked separately. Having scope story points separately tracked, better product and financial management of the project can be achieved. By tracking effort story points independently, re-estimation for better progress management can be done without impacting scope measures. Appropriate periodic re-estimation of effort story points empirically basing on actual efforts instead of stale and somewhat arbitrarily assigned values at the beginning improves predictability of delivery schedule and collaboration coordination. Because of planned re-estimation, there should be no fear of using ideal work days as measures, which reduces confusion and difficulties in planning and estimating. Visualization of the correlation between the scope and effort story point velocities provides another means to assist with work prioritization.

1. Introduction

In one of the Agile practices, business value delivering functionalities/features are organized into units called stories. These stories are often relatively sized and recorded using a parameter called story point. With consistent and proper story sizing, story points are good indicators of scope and effort. Total story points are often interpreted as the total scope as well as the total effort for the project. However, scope and effort are very different concepts and have different quantitative and qualitative variations in the course of a project.

As more knowledge is gained about the nature of the stories, previous effort estimations often need revision. In other words, story points will need to be changed to reflect the new effort estimation. As a result, scope measure will inevitably and inappropriately change as well since both effort and scope are tracked with story points. Depending on whether the new total story point is higher or lower than before, scope inflation or deflation will occur respectively. By having an effort story point attached to each story instead, we can safely do re-estimation without causing inaccurate scope change. With re-estimation as part of the process, the fear and worry of estimating in ideal man days also disappear (see http://agilesanity.blogspot.com for details )

On the other hand, a highly valuable and complicated feature/functionality might take very little effort to complete. For example, the shopping cart of a web application can be easily implemented by purchasing and integrating existing tool kits. On the contrary, a low value feature/functionality might take a lot of effort to deliver. For instance, to add contextual help for an air ticket booking web application might sound like a simple one liner feature, but it actually entails a lot of work behind the scene. The gist of these examples illustrate that feature size and effort size are not necessarily positively correlated with business value.

Tracking scope story points separately has the additional benefit of increase ease in associating business values to the stories. This will help identification of project progress variance analogous to the use of planned/earned/actual values analysis common place in established project management discipline.

The correlation between scope and effort velocities is also another good visualization tool for understanding project progress, resource usage, and hence prioritization.

But the most immediate benefit of scope and effort story point differentiation is reduction of abstraction. Clarity is gold.

However, if we make story point management too complicated, then the ROI might not be justifiable. As in anything, balance is the key. There is a Confucius saying, "The fools never worry about balance, but the smarts try too hard to balance and losing it." So being agile in spirit is the true way.

2. Scope Management with Scope Story Points

Scope story points, or simply scope points, can be allocated as simple as one point per identified story. So, if we have 19 stories, then we will have 19 scope points, which represent the total scope at the moment. This is acceptable when stories are supplemented with effort story points.

However, there are more useful ways of assigning scope points. For example, we can associate scope points with business values. Let’s say the project is about producing a PC car racing game, which is expected to make a net profit of 5 million dollars in 3 years. Then, the upper bound for total scope points can be assigned 5 million (the lower bound can be the cost of the project). In other words, completing 5 million scope points will mean that all essential features of the game are developed. With this lump sum figure as the reference point, consideration of addition or removal of features/functionalities can be made by taking into account whether such action will increase enough sales/profit to justify the extra cost based on effort story points (to be discussed later). So, better decisions can be made towards scope changes, and resource allocation.

A few more words on scope point assignment with the PC car racing game example. Sometimes, there are critical inter-dependent stories which aggregate completion is required for a product to be shippable. If the majority of stories are under this category, then the burn up or burn down chart of scope points will be useful. However, if, say, less than half the stories are critical and inter-dependent, then, these charts will not be as useful because the scope velocity of non-critical independent tasks does not depict a true picture of how far the project is progressing towards completion if the critical path is lagging behind. This is the case because the risk and unknown are not explored in the critical path. The simplest way is to track critical inter-dependent stories separately.

With scope point come scope velocity, and scope burn up chart. The former is not as useful as effort velocity (to be addressed later) in terms of completion prediction. The latter, on the other hand, is the better indicator of earned values than effort burn up. For more information on earned value management, please see "Project Management Body of Knowledge - 3rd Edition".

3. Effort Management with Effort Story Points

See "Adaptive Agile Effort Management" post in http://agilesanity.blogspot.com for details.

4. Relationship between Scope and Effort Story Points

The correlation between scope and effort story points is a good indicator of ROI management. This helps prioritizing of stories. For example, if the burn up charts of both effort and scope indicate positive correlation, then we are delivering values proportional to effort. If the scope burn up is at a higher rate than effort, then it means we are delivering higher values with relatively lower cost. The contrary will indicate that we are spending a lot of efforts delivering little values. Of course, there are times we have to do this because of resource constraints or inter-dependencies among tasks which constitute the stories. And even among stories, dependencies can be hard to avoid at times.

5. Conclusion

In this article, the cost and benefits of separating story points into scope and effort points are explained. It is not difficult to separate them. The simplest way is to assign one point per business value delivering story, and then track effort points just like we do with story points nowadays. More sophistication management of scope points is to associate business values. There are many ways to do this. How much efforts should be spent in sophisticated scope point management is subject to the ROI of such endeavors.