Estimating How Much and How Long

Estimating: how long and how much

First, let’s dive into what to estimate, when to estimate and how to estimate.

When I refer to product backlog items -- PBIs for short -- that’s what we call our requirements in Scrum. It’s all the work that we need to do to our business application so that this has the highest possible value for our stakeholders.

In the past, we used to write PBIs on 5’x3’ index cards. That card metaphor got carried over to backlog management applications, like Azure DevOps, which represent those cards on our screens.

Most of our PBIs are user stories, which capture the essence of what a stakeholder needs our application to do and why. High-level requirements are known as epic user stories. They are just user stories that are too big and complex to get done in a single sprint. Later, we’ll split the epics down into smaller, implementable user stories.

Product backlog items, cards, stories, epics. They are all similar ways we talk about our requirements on an agile business apps project.

But what they are not is specifications. If you are trying to capture and write detailed requirements at the start of a project before you start development, that’s a hallmark of a fixed mindset, a throwback to the waterfall days where each phase is completed before moving on. Upfront analysis, even if you’re using user stories, means that you’re capturing requirements at the point of peak ignorance: when everyone knows the least.

In agile projects, I encourage my teams to delay discovering the details about a requirement until the last possible moment. Usually, this is a few weeks (a sprint or two) before we intend to start developing the feature. 

Using just-in-time analysis means we get to benefit from our understanding of everything we’ve already built for our users. Our knowledge of their requirements is so much greater than it was at the start of the project. The users’ knowledge of what the application can already do and needs to do is also many times greater than it was at the start of the project.

However, we usually don’t get a green light to start the project until we can show someone how much it’s going to cost and how long it’s going to take. That someone is called money bags or financial sponsor if you want to get fancy.

To satisfy the financial sponsor’s curiosity, I’ll give them a quick estimate of how long it’ll take and how much it’ll cost based on a set of high-level requirements. Visualising those requirements in a user story map is the best method I’ve found for reviewing the scope, timeline, resources and costs with the application’s sponsors and getting their approval. We’ll dive deeper into story mapping in another podcast episode. but we’ll come back to that later.

In my product backlog, we’ll have epics and user stories. And those PBIs will have estimates in story points. We also have three other types of product backlog items:

• Chores: work the development team needs to do that has no appreciable value for our users, such as refactoring our plugins
• Spikes: research work we need to do to improve our knowledge, such as evaluating technical options and recommending the best design pattern for a set of requirements
• Bugs: defects discovered in our production and non-production environments that need to get resolved.

I don’t recommend estimating chores, spikes or bugs. Sometimes it can useful to forecast how much work it’ll take to get our chores done, spikes completed, and bugs squashed -- and many teams do estimate this work -- but the downside is that sometimes we include this work in our measure of how much valuable work we got done in a sprint. We call this our velocity. 

I like to think of our velocity as a measure of the valuable features we’re creating for our users. If we include a 5-point user story in our velocity, and then include a 2-point bug that we found in that user story, we didn’t create 7 points of value. In fact, the bug is a sign that there’s an issue with our quality and that the 5-point story wasn’t done properly. So I only include the story points from done user stories in my measure of velocity.

I don’t estimate chores, spikes and bugs. I definitely don’t include working on chores, spikes, and bugs in my velocity calculations.

When to estimate

The need to estimate new requirements comes up all the time. Especially on an agile business applications project where the stakeholders know that we have an open, transparent and flexible product backlog.

Like many tasks in life, estimating product backlog items is much more efficient when we batch them together and estimate a lot of them in a concentrated session where we focus purely on estimating work, with no distractions.

I concentrate my estimation activity into a workshop at the start of the project, and a workshop each sprint. When I say ‘a workshop’ that might mean one or more sessions depending on how much unestimated work we need to estimate, but usually it’s just one.

Before the project starts, when our stakeholders want to know how much it’s going to cost and how long it’s going to take, then my teams estimate the epic user stories in our user story map, which is that two-dimensional visualisation of our product backlog.

Once the project has started, and we’ve refined one or two epics into smaller user stories and we’re adding new user stories into the backlog, then my teams estimate those user stories during story time workshops. Storytime workshops aren’t an event in the Scrum framework, but Scrum says we should set aside some time each sprint to refine our product backlog and I’ve found it useful in my Dynamics 365 and Power Apps projects to schedule backlog refinement as an event in our calendars. We call it storytime.

During story time workshops the product owner shares any new user stories with the development team. She helps them gain a shared understanding so that they have sufficient knowledge of it to be able to compare its complexity to other user stories so they can estimate it.

Importantly, they don’t need all the details of the story before they estimate it. They don’t need to have agreed on a specific technical design, although often they have a probable design in mind when they estimate a user story, they need to know enough to compare the probable effort to design, develop, test and deploy this feature into production. 

Estimating without every single detail requires that we make some assumptions, and it can be useful to make a note of any important assumptions that affected our estimate. Sometimes we’ll estimate higher than actual, sometimes lower. But it usually works out in the end.

My teams very rarely re-estimate a story once it’s been estimated. There have been a handful of times, usually when there’s a bigger gap than usual between when we estimated the story and when we actually started working on it, and we find that we’ve got some new knowledge now that completely invalidates our earlier assumption on which the estimation was based.

Estimating units and scale

Just before we dive into the mechanics of how we estimate, let’s quickly recap our estimation units.

I like to use user story points as my estimation units. They are an arbitrary unit that we use to compare the relative complexity of any two stories.

When we estimate user stories, we use the smaller numbers in our modified Fibonacci sequence: 1, 2, 3, 5, and 8.

When we estimate epics, we use the bigger numbers in a modified Fibonacci scale: 13, 20, 40, 60 and 100.

What I often find is that when we split epic user stories into small user stories, is that the sum of the estimates of the small user stories never adds up to the estimate of the original epic.

Let’s say we split a 20-point epic into 5 user stories. Those might have estimates of 2, 3, 5, 5 and 8 points. The total is 23 user stories points split out of a 20-point epic. That’s not uncommon. 

If you need to strictly manage your backlog to the original estimate, then you’ll need to defer some of the user stories split from the epic until later. In our example, we’d try defer user stories worth 3 or more points to later in our backlog so we can stick to around 20 points for this epic.

Now we have agreed our estimation units and scale, the next thing we need before we start estimating our backlog is a baseline story or a baseline epic.

A baseline story is a story that we’ll use to compare every other story against. 

I like to pick a relatively small (but not the smallest) user story that feels well-understood by the development team. Usually, it’s a common requirement that we’ve seen on several projects before. Everyone understands the title, description and the acceptance criteria. It’s the type of story most of the team has experience getting done and deployed into production without too much drama.

It’s a 2 or 3-point story in our user story point scale. That’s our baseline. We compare every unestimated user story to our baseline using our relative estimation method.

We can do the same for epics. Find an epic that feels well-understood, and we call that a 20-point or perhaps a 40-point epic. And now we can compare all the other epics to our baseline.

Over time, we might even have a collection of baseline stories that remind the team what a 1, 2, 3, 5, and 8 story point user story looked like in terms of the effort that was required to design, develop, test and deploy it.

OK. We’ve got our unestimated backlog. We have agreed our units and scale and selected a baseline user story or epic. Let’s estimate!

How to estimate: planning poker

We want estimates that are reasonably accurate, and we want the estimation process to yield results quickly. Spending hours estimating work that will take a day or two to get done isn’t a good use of time.

We also don’t want the estimates to be influenced before everyone has had a chance to understand the requirement. We don’t want the product owner or an experienced team member telling us what she thinks the estimate should be or needs to be. That’s known as anchoring. Instead, we want everyone’s unique perspective and expertise to influence the estimate.

Relative estimation using a game called Planning Poker helps us achieve these objectives.

Here’s how it works.

The product owner discusses an unestimated user story for a moment or two and answers the development team’s questions about it as best she can.

Each development team member compares the unestimated user story to our baseline user story privately chooses the story point estimate from our agreed scale. If our baseline was a 2-point story, and you think the unestimated story was at least twice as complex, you’d choose a 5.  If it was half as complex, you’d choose a 1.

Once everyone has estimated the story, we all reveal our estimates at the same time. This way we avoid anyone anchoring anyone else’s estimates.

If everyone’s estimate is the same, then we have a consensus. That’s our estimate.

If not, then we discuss the story some more then everyone estimates again. During the discussion, we often ask the developers with the highest and lowest estimates to describe how they arrived at their estimates.

The game is often facilitated by the scrum master who keeps the game flowing, ensures that everyone’s perspectives are being included and help the team reach consensus quickly.

There are Planning Poker applications if you’re working as a distributed team and want to use an app the help facilitate the meeting.

If you’re co-located then your team might want to buy Planning Poker card decks, but honestly, I find it just as easy to type the estimate into the Calculator app on my mobile phone and then reveal once everyone else is ready.

Estimation ranges

At the start of a project, once you have estimated your initial product backlog by visualising it in a user story map and estimating all the epic user stories with planning poker, you’ll arrive at a total estimate of all the work required to meet your requirements. 

You might even have sliced this estimate into releases so that you can deliver value as early as possible to your users.

But your application’s stakeholders, especially moneybags, still want to know how long it’s going to take and how much it’s going to cost.

Telling your financial sponsor that the backlog is 600 story points isn’t going to induce her to whip out her credit card.

We need to convert that total backlog estimate, or each of the release slices, into time and money.

We estimate the size and derive duration.

We derive the duration by taking our total estimated size and dividing it by our estimated velocity.

Remember, our velocity is how much value we create within a given timeframe. We usually measure it as the number of story points done each sprint, where a sprint is a one-week or two-week timebox. 

If the project hasn’t started yet, I usually say two-week sprints, at this stage, but the scrum team can change their cadence later.

Let’s say our backlog is 600 points. If we estimate that our velocity is 60 points per 2-week sprint, then it’ll take 10 two-week sprints to get all our work done. That’s about 5 months.

How do we estimate our velocity? I recommend going back to the baseline user story. Ask the development team to estimate how many stories this size they could get done in two weeks. If we had a 2-point baseline, and the team estimated they could complete 30 stories that size in two weeks, then our estimated velocity is 60 points.

Life is unpredictable. And estimates are just estimates. They are not forecasts, predictions or commitments.

To help my stakeholders understand this, I usually provide two estimated velocities: high and low. We’ll see actual velocities close to the higher estimated velocity in sprints where luck was on our side. We’ll see actual velocities closer to the lower estimated velocity if we’re blocked by impediments, or we spend a lot of time on spikes, chores and bugs. Over time, we expect our velocity to increase as the team improves it’s working practices.

If 60 points per sprint is our high-velocity estimate and 40 points per sprint is our low-velocity estimate then our 600 point backlog will take between 10 and 15 sprints to get done. That’s somewhere between 20 to 30 weeks or 5 to 7 months.

With me so far?

To answer moneybags’ other question -- how much is it going to cost -- we take our derived duration and multiple it by our run rate.

Our run rate is the fully-loaded cost of the expected Scrum team. The cost of the team members salaries or fees, plus whatever overhead you need to include such as equipment, space, travel, accommodation and so on.

If our full-loaded run rate is $20,000 per week, that’s $40,000 per two-week sprint. Our 600 point backlog is going to take 10 to 15 sprints, which is $400,000 to $600,000.

Estimating the backlog example

If you listened to part 1 of this estimation series in Amazing Apps episode 2, you might remember my financial services client in Sydney. They audit self-managed superannuation funds and wanted to build a business app to make the auditing process more efficient.

Their board of directors wanted to know: how long is it going to take and how much was it going to cost?

The product owner and I built a user story map that revealed 38 epic user stories.

12 epics to build a minimum viable product that they could show to their prospective users to get some feedback. Another 16 epics were needed for the first production release, and 10 epics for the follow-up release.

Working with the developers, we estimated the total effort to be 314 points in the MVP and 550 points in the first production release. We didn’t feel like we have enough knowledge of the epics in the second production release to be able to estimate it. We felt it would be better to tell the board this, rather than guess some numbers.

The development team estimated its velocity to be 50 points per sprint. This was based on another app they had already built and integrated with Dynamics 365 for this company. We used that as the high velocity and used 40 points per sprint as the low velocity that we’d use with the board.

The MVP was 12 epics estimated at 314 points. At 40 points per 1-week sprint, that’s 8 weeks. And with a weekly run rate of $10,200, the estimated cost of the MVP is $81,600.

The first production release was another 16 epics estimated at 550 points. At 40 points per 1-week sprint, that’s 14 weeks. With the $10,200 per week run rate, the first production release would cost $142,800.

The total cost to get to the first production release where they could charge a subscription fee to their users is going to be $224,400, which is the cost of the MVP plus the first production release. It’ll take about 22 weeks. So if we start in August, there’s a good chance we can release the MVP in early October and to production after the summer holidays in January.

Game on!

The board has improved the investment and they’re off.

That’s how I estimate how long it’ll take and how much it’ll cost for my Microsoft Business Applications projects.

The story mapping workshops and running the numbers takes a day or two for a medium-sized project. It’ll take a week or two if you expect to spend years building an enterprise-scale application and need more rigour and polished deliverables to support a business case or a proposal.

But in any case, it’s much quicker than the protracted analysis and design phases of the old Microsoft Dynamics SureStep methodology. The result, I’d argue, is more accurate, more receptive to change, and more compelling.