Scoping Project Phase in Agile—How To Make Sprint Planning Effective?

Capacity dictates each team’s day-to-day work. “What can we do? How much can we get done? Will we make it on time?” Reasonable capacity planning (or scoping) is important—without a good scope, your project will run out of budget, time, or both. And nobody likes an impossible deadline, right? The real problem is that no deadline seems impossible when it’s first set. “We’ll fit it in” is something I kept hearing surprisingly often with many teams I myself worked with. Too often, however, it was nothing more than just a fool’s hope.

Regardless of the process you use, this article should be relevant to your day-to-day work, as I will not be discussing methodologies such as Scrum, Lean, or XP… As long as you use an iterative process, you’ll be fine. Additionally, for the purposes of this piece I will not be taking iteration length or release cycles into account—they are usually too project-specific to discuss in a general article like this one. For example, if you use Scrum, your sprints can be as long or as short as you like.

However, I will show you how to fit the right number of planning items (such as user stories or tasks) into the backlog of your current iteration and demonstrate three kinds of capacity planning: time estimates; story points; and reverse scoping. This article will also give you a good overview of the shortcomings inherent in the two kinds of numerical estimates—time estimates and story points—that continue to be the most popular methods of scoping. The piece will also offer you a handful of suggestions on how to improve your capacity planning using alternative methods. Read on to find out which method is the most effective and when.

Don’t Use Numerical Estimates to Determine Scope

There are two kinds of numerical estimates I want to discuss here:

1. Time-based estimates
2. Story points

Time Estimates

We’ll begin with time estimates—many project managers I know, myself included, began their careers in software development, thinking that particular estimation method was one-and-only choice. In some projects it might serve its purpose but I notice some shortcomings. Here’s the example. When a project manager asks, “How long will it take?”, a developer ponders the question for a while and replies, “I think four hours or so.” Done. We can move to the next item on the agenda. Hence, this method bases on someone’s sheer presumptions which might be sometimes far from reality but you find this out afterwards, though. In case of similar tasks occurring regularly, one knows suggested time and the issue becomes less troublesome.

A manager using time estimates will often be tempted to use something like a Gantt chart, a type of a bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal and summary elements of a project.

Modern Gantt charts also outline the interdependencies between individual activities—and identify which activities precede which. The problem with Gantt charts is that complexity and interdependencies are almost always bound to crumble, go down like dominoes. Mostly because the waterfall method doesn’t work well in the world of agile methodologies. Therefore, I would recommend it only for well-specified, short-lived projects (less than six months), targeted at a stable market and built in a proven technology. It might work wonders but only in the environment without any unknowns. Quite a pipe dream, huh?

Although I do realize that in modern projects Gantt charts are used ever less frequently than in the past, what I would nevertheless like to point out here are the causal dependencies between backlog items that are often built into the mindset of time estimates. Mostly because it’s not a very refined method of capacity analysis.

Story Points

Story points are a unit of measurement for estimating the effort required to implement a product backlog item. When estimating using story points, you assign a point value to each item, the value itself being a measure of difficulty rather than time. For example, if two backlog items are both given two story points, they are similarly difficult to implement. They are also more difficult to implement than items with one story point and less difficult to implement that items with three story points. Sounds simple, but there’s an important conclusion hidden behind these obvious facts. While hourly time estimates are absolute, story points are relative. A story points-based system worked out by one team might be meaningless to another.

Velocity Issues

Relativity brings us to velocity, an highly important concept in the world of story points. Another invented, team-specific measure of how much work the team can do. Velocity is the number of points’ worth of stories the team can implement in a single release. It is also an average value—we measure how many story points the team was able to successfully implement in the very first iteration, and then adjust the number after each iteration, making the number more accurate as time goes by. So, for example, if we lose a team member, our velocity will go down over time. If we gain an additional team member, velocity will increase. Thus, velocity automatically adjusts to the conditions the team is facing which in itself is a huge improvement over absolute estimates.

However, I ultimately grew to dislike story points, too. People who use story points usually do so in tandem with something like burn-down charts, which is a graphical representation of work left to do versus time. The outstanding backlog is usually represented on the vertical axis, with time along the horizontal. Since story points are relative, rather than absolute, and start or finish dates can’t be positively deduced, progress is tracked using burn-down charts rather than with devices like the Gantt chart.

 

Still, burn-down charts are easy to manipulate. They are quite like profit projections and have a tendency to turn in the direction of their authors’ dreams or intentions. Project Managers using it should be aware of this threat and treat it rather like a guideline than “ideal” reliable chart. Meanwhile, the math-based nature of velocity makes it a rather cumbersome instrument, even if tools like JIRA help calculate the result. Also, averaging only works over longer periods of time—in fact, any change to the conditions your team is currently facing will destabilize velocity for a few iterations.

Using Reverse Scoping

Here’s a third alternative, which I call reverse scoping because it reverses the usual capacity planning process. It hasn’t been implemented at Monterail yet, as it’s highly time-consuming but work is in progress.

Normally, a planner would plan capacity based on some estimates of the product backlog items. If a sprint can fit twenty story points, the team will look for backlog items with estimates that add up to twenty points. For example, two items with five story points; three items with three story points; one item with one story point. Reverse scoping, on the other hand, requires you to:

1. Choose a product backlog item you want to get done without estimating it;
2. Cecide up front how much time or money you can spend to get it done;
3. Either cut the scope or expand it based on your budget.

In other words: you get what you can spend. If you spend too much, you cut the scope. But if you spend too little, you can add new layers of complexity because you still have resources to do so. Either way, at the end of the iteration, you get something done—but there’s no bad blood between the delivery team and the business stakeholders because the only thing promised was a release that wouldn’t go over budget. Higher budgets mean greater quality or complexity. Lower budgets mean the opposite.

You can budget either time or money. If it’s the latter, you decide that you can spend up to $XX,XXX on the project and adjust the scope accordingly to the current burn rate throughout the project. With time budgets, you set deadline up front and then adjust the scope of the project to hit the deadline.

Money vs. Time

Money-based reverse scoping is much easier to prioritize. Making a choice between projects A and B is easy if you know that project A will cost $5,000 in order to bring a projected value of $6,000—and that project B will cost $7,000 but bring $10,000 in value. This is an extremely effective method for negotiating scope with non-technical business stakeholders. Non-technical stakeholders understand budgets better than they do abstract story points. And with enough good will, every time estimate can be contested. Budgets, however, suggest value. I call that value-based planning.

Time-based reverse scoping acknowledges that deadlines are good. People naturally think in deadlines, and there’s nothing wrong with that. Much of the business world is deadline-oriented, too. For example, for many companies selling consumer hardware products, the holiday season is a natural deadline. If we allow for flexible scope when trying to meet the deadline, the delivery team can make autonomous decisions on where to cut the scope while being sure that the business stakeholders will be fine with the result. Why? Because anything more would either take too much time or be too expensive. In my experience, business owners often get frustrated at teams for freezing the scope. But I have never seen a businessperson mad at freezing the budget. If you are assertive and say the magic words, “Expanding the scope will make us go over budget,” they will usually accept it.

Let’s Start Planning

Personally, I like reverse scoping best, but my suggestion is to change your scoping method once in a while if that’s possible. Why? To break routine. Routine and making assumptions about the scope are the biggest enemies of every planner.

If task A looks similar to task B, it’ll produce a similar estimate; but the technical challenge might end up being entirely different, so such comparisons are usually false. A team that’s eager to learn new stuff won’t mind the shake-up if it’s done sensibly and planned. In fact, they may appreciate the new perspective.