Due to his glasses, Michael’s estimate of Jane’s distance from him is 14.3% further away than she actually is–at any given moment. How would you describe his estimate?

Precise, but not accurate.

Wait, what’s the difference between the two again?

Precise means the numbers you are seeing are repeatable. Often down to multiple digits after the decimal point. You can be pretty confident that when you do the experiment again, you’ll get the same result.

But that’s not necessarily true with an accurate result. An accurate result is one that is close to the actual value. For Michael’s scale to be accurate but not precise, it would be producing numbers close to the actual value, but not the same number each time. In estimating knowledge work, accuracy bests precision.

This above 2×2 applies to estimation of work in a knowledge work context. Ideally, everyone involved wants estimates to have both high accuracy and high precision. But at the beginning of a new initiative, it will most likely be low accuracy and low precision. Because at that point you know the least you possibly can. From the example aboce, Michael’s estimate lies in the top left box. However, what we actually prefer to that is the bottom right one…if we can’t have the top right. High accuracy makes it much easier to plan out the upcoming work.

One way of skewing towards accuracy and away from precision is by making it difficult to be precise. Instead of trying to estimate absolute sizes of stories, i.e. 3 days, we can estimate only relative size, i.e. 2 story points.

Relative sizing gives us enough to negotiate business priorities given the size of each story, without tempting fate in terms of blaming: “You said it would only take 3 days, and blah blah blah”. This isn’t healthy, productive, or fun. So why even go there?

These relative sizes still allow for some reasoning; however, direct numerical inferences are deliberately imprecise. For example, you can add up how many story points there will be for a larger epic. You will need to allow for a lot of variance on the individual stories. But on the basis of the “law of large numbers” from statistics, this variance will tend to average itself out. Based on this you can get a feel for how one epic compares to another for example.

1. Estimate story points directly

For this, the first place to start is the Fibonacci sequence, as a way to express relative size. They’re numbers. The sequence itself is very simple. Each number in the sequence is the sum of the preceding two values. This ensures that it roughly doubles each time a new number is generated, but not precisely (Hah! low precision!).

There are visualizations of the Fibonacci sequences like the one above, where you can see that there is a clear difference between each step. In practice, this type of sizing will help you get beyond a “to do list”, where everything seems to be the same level of effort. It’s not. And that’s the point.

Here is a recommended breakdown in my favorite free tool for estimation: planitpoker.com:

It’s typically good to top out at a maximum size to make sure that stories stay small. Over a certain size it just feels too big, and the estimation discussion stops being useful. At that point, a big story should probably be broken into smaller subtasks, each of which should be estimated using the above sizing numbers.

2. Translate T-shirt sizes into story points

For teams struggling with letting go of absolute estimates, the T-Shirt approach gives you the best of both worlds. Essentially you have the team estimate using relative T-Shirt sizes. Then you translate the team’s input into story points. This reinforces the relative nature of story points, while still giving you something more concrete to work with for velocity purposes.

Using the planitpoker.com interface, you can set it here:

3. Ron Jeffries’ option of 2 days max/task

This option came out of a big debate years ago on the scrumdevelopment yahoo groups mailing list. I admittedly have never tried this myself, but it’s worth considering as an alternative approach to estimation. Or a thought experiment at minimum. Basically, at the time Ron Jeffries (@RonJeffries) was arguing against estimation in general. He posited that:

• we should stop estimating
• limit stories to 2 days of work
• if you expect a story to take longer than 2 days, then break it down into multiple sub-stories

This way, you significantly reduce the need for an explicit estimation discussion. And you can manage workload and scope based on the number of issues you want to complete. If stories are assumed to be of equivalent size at a worst case scenario, i.e. 2 days/story, then you can derive your delivery date from the number of stories you have. Assume all remaining stories take 2 days, i.e. the worst case scenario, and add the number of work days to today’s date.

In practice, stories are often larger if they have “business value” and therefore can’t be easily broken down. Thus it’s hard to pigeonhole them into such a framework. By business value, I mean anything that would be of value to a customer for non-technical reasons. But you can put such a limit on sub-tasks of stories. And therefore just count the number of sub-tasks.

This approach kind of turns software development into a release checklist of stuff that must be finished. All of the tasks are small. It also means that there are a lot of stories and tasks flying around. This require extra management & coordination work to maintain it. Either by the team or a delivery manager.

And also I suspect it’s hard for senior stakeholders to see the forest for the trees, if you just have a long list of tasks. What will be done by when? Even though you can change the order of what’s done, it’s hard for anyone who isn’t intimately involved with the details to understand what’s happening at a glance.

Finally, I do think in this case you lose out on the design discussions which happen during estimation. You only break down stories or tasks if they are “too big”. Therefore, you won’t ask questions like “what is the best way to approach this?” before starting the work. It could impact the quality of what’s delivered. And also get team members to spend time on work that is thrown away or low priority. In my opinion, this is human nature. We need to be deliberate about priorities; if we’re not, they won’t happen.

So here are a couple of aspects of this approach this Ron himself points out when using this approach to figure out when we’ll be done:

• What if all stories were approximately the same size. Then what could we do with story estimates that we couldn’t do with story counts?
• What if all stories were one acceptance test? What could we do with story estimates that we couldn’t do with story counts (or, now, acceptance test counts)?

4. #NoEstimates

Finally, as an honorable mention, there is the whole #NoEstimates argument, which has been popular in software development circles. Basically, the approach claims that:

• There is a lot of scope uncertainty for most of a software project, often more than the first half of the overall schedule (i.e. >50% scope variation)
• Making estimates takes time and therefore is expensive, particularly if there are tight deadlines and high costs of delay
• Estimates don’t contribute explicit value to final customers (i.e. they are about internal company operations and for planning purposes only)
• Holding the team accountable to time estimates means that they are incentivized to sacrifice other aspects of the work, such as lowering quality or accruing technical debt, which isn’t visible but with material consequences

There a number of other nuances. Basically for any knowledge work where there are a lot of dependencies (like in software), you might be better off not messing around with estimating at all. Just get on with the work.

Personally, I think estimation sessions are useful mostly for the purpose of having a priori how I’d do this discussions. #NoEstimates throws the baby out with the bathwater.

Also, by their very nature, most tasks on a large project will take different amounts of time (assuming we don’t take the approach from #3 above). And technical people are the best placed to figure that out and share it with everyone. They have a unique and often common perspective, which the rest of the company lacks.

The team doesn’t work in a vacuum. So timing becomes important, if not critical, to getting the full value of the efforts being made.

Doesn’t all this estimation just mean there is less time to do the actual work?

This concern boils down to one of efficiency. Usually, the asker assumes that the time to complete something this fixed and that the team’s primary goal is squeeze out as much as output as they can in that time frame.

In practice, though, effectiveness trumps efficiency. There is not point in doing something quickly, if it doesn’t need to be done at all. To use the old Steven Covey analogy, is the ladder leaning against the right wall?

And for better or worse, product teams of 2 or more people have exactly this problem. In addition to coordinating work among everyone. New product development is fraught with uncertainty, including technical uncertainty in many cases. So what the team investigates, validates, and builds in what order is critical. While efficiency is a concern, any time spent on making the new product development more efficient is likely to be thrown away if the goal changes. So efficiency won’t matter in that case anyway.

Case study: Distributed estimation

A pretty common trope nowadays is that larger companies have distributed teams, often across many locations and time zones. In the early days of agile, it was quite difficult to estimate under these conditions. A lot of the nuance and genuine discussion required was simply lost in the ether. And until recently, the tooling for distributed work didn’t exist. Well, that’s changed.

At most client sites, there will already be some kind of story tracking system in place such as Jira or Trello. It is possible to add a “story points” field to the template for a story. Typically, this involves speaking with the owner or local administrator of this system, but is relatively straightforward.

We don’t actually need any more functionality in the story tracking system. It’s nice to be able to display the story points where relevant afterwards. Jira, for example, has quite useful reporting based on story point estimates right out of the box. Trello has addons. Other agile management systems presumably have the same.

On a typical planning sessions, the product owner or business analyst (BA) spins up a session of planitpoker.com. One of the nice features of this system is that it doesn’t require you to set up an account or even really authenticate. Once a ‘room’ is set up, the BA shares out the link to everyone estimating. Everyone can sign onto the board without setting up an account.

At that point, typically I am sharing my screen with either the description of the story or any relevant collateral such as a spreadsheet, a miro board, or showing and explaining why the current version is missing a feature. I enter the story tracking id into planitpoker.com after we’ve discussed what it is. And then everyone votes on the number of story points to estimate the complexity of the task. Once this is complete for everyone, we look at the distribution of votes. If it’s wide, we discuss and vote again. We keep doing the same until it’s pretty much the same across the team. If for example, we decide that a particular story is a 5 story point size, we just type in that value into Jira or Trello.

You don’t need any fancy or even paid plugins to do this. It’s enough to be able to share your screen and have a discussion with everyone involved. In terms of estimation, the heavy lifting is done using planitpoker.com. Once a round of planning poker finishes, it can be discarded. And then you type in the estimates in the story tracking system, where you need them later.

When stumbling onto this approach, I think the key learning was that you don’t actually need everything to be done in your main story tracking system. All you really need to do is have a good debate, and then store the outcome of the estimation. And the conversations you have while estimating are the most important art of the process anyway.

Case study: use T-Shirts for first cut of backlog estimation, then translate to story points

In this scenario, we had a large team, a massive scope, and a lot of uncertainty around exactly how the product would work. I felt we just needed to get started on the work in order to reduce the technical uncertainty behind the work. So forcing the whole team to spend hours or days estimating something they don’t understand would have been a waste of everyone’s time. If they started the work, we could have more meaningful estimation discussions later. For context, this was an infrastructure project.

The architect involved had put together a big graph in draw.io for how the entire system would work. It had rapidly become a symbol in the company of something highly complicated that nobody, except for him, actually understood. What didn’t help was that developers in the company didn’t have much experience with cloud technology. And it was relatively new stuff, even for him.

Steps taken:

1. Put together a vizualization or map of the scope which needs to be built, which was particularly necessary here given that we needed to build infrastructure.
2. We listed out the ~47 different pieces of work, most of them mapping to components of the big drawo.io microservice cloud to a spreadsheet.
3. As the architect felt uncomfortable assigning story points given the level of uncertainty, I asked him to use TShirt sizing for all 47 items.
4. If you need to do this yourself, start with what you think is average and assign them all an M. Compare everything else to those items, i.e. this is a little smaller so it’s an S, whereas this is really minor so it’s an XXS.
5. Given all of the above are sized, map the TShirt sizes to Fibonnaci sequence numbers. For example, XXS is a 1. XS is a 2. And so on.
6. Then use those numbers as story points and continue planning from there.

Using this slightly circuitous route, we got to a story point estimate which I felt was accurate. It wasn’t precise,but that was acceptable at this stage. And the development team got started quickly on the work.

Case Study: Estimating roadmap items (to appease overachieving stakeholders)

Sometimes there is pressure to plan out a big roadmap up front for a new product. The justification that I often here, is that we want to know when “we’re done”. Personally, I don’t feel knowing that is actually useful, especially from a business perspective. What I’d prefer to focus on is getting to first revenue and profitability. Estimating something a few years out in detail–when you barely understand it–is just a waste of time. And likely to be inaccurate.

All that said, it’s useful to know your options for the future, and to also have some idea how much effort adding any given option will take. At a high level, that is probably good enough.

To keep everyone happy, the simplest approach is to use TShirt sizing of Epics. Some things are relatively small and quick. Some are huge. Some are in-between. The development team are the best judges of that, since they will need to do the work.

Clearly the TShirts for epics (groups of stories) will not be equivalent to TShirts used for stories. If you are pressed to translate the epic TShirts into story points, I’d suggest provided a range estimate for each one. For example, an M size epic is 6-10 weeks. Range estimates can still be used for planning, but aren’t explicit commitments to deliver on a specific day. And they’re good enough to identify if you know up front if you’ll be late.

Some estimation is better than nothing at all. It’s useful to just do a quick pass without going into all of the minute detail when brainstorming a roadmap. And T-Shirt epics give you the flexbility to do just that.

Case study: Nitty-gritty technical estimation in person

Geek out time, analog style. In one office! This experience, as well as similar ones, convinced me that estimating in person works best…if you can swing it. Fly people in if you have to. 🙂

In the early days of when I was a developer, my team and I inherited a codebase in C++ of 17 different components. Most of them were written using Borland C++, a compiler that was once cutting edge but had since largely fallen out of mainstream use. In addition to the compiler, the code used a lot of abstractions specific to using libraries shipped with the compiler. We decided that we need to get into a more up-to-date environment, to take advantage of the significant performance gains in newer compilers and also so that it would be easier to work with (and probably recruit more help for).

With an architect and another developer, we booked a small meeting room for half a day, to plan out the work. First we talked about what needed to be done. As we discussed each story, we wrote them down on index cards. We stuck them on the table, because we wanted to see all of them at once.

Then, to estimate, the work we also went analog. Essentially, we took the business cards of a former colleague who’d left the company, and wrote the Fibonacci sequence on the back of a handful cards. Then each of us took a set of the cards. We started discussing each index card, one by one. We each used one card to indicate how many story points worth of complexity lied behind each task, laying it face down on the table. Then we flipped over the cards. If there was a difference in the numbers, we got into technical discussions to convince each other that the story was simpler or harder than we expected.

After a few hours of this estimation boiler room, we had a lot of questions about one particular component which we didn’t know that well. So we waltzed back to our desks to spend the afternoon looking at the existing code, and to inform our estimates even further. Finally, the next day we reconvened and finished off the complete estimation session for the entire piece of work.

Once we had the aggregate story point estimate, we provided internal company stakeholders a relatively narrow elapsed time range estimate based on how long our story points typically took. This gave them enough information to be able to plan around our efforts, especially the pessimistic estimate. The range estimate was also intentionally not precise, even though we did feel it was accurate at the time.

In practice, the estimate was correct, although the route to get there was kind of roundabout. Most of the tasks we did involved making a breaking change to the code in the new compiler. Then cleaning up the errors and warnings which resulted. The lists of problems were quite long, but then often making one fix suddenly fixed 30 errors in one go. So in short, we couldn’t have really known this up front anyway.

But the estimate was close enough to be useful for planning purposes.

Key takeaways

1. You don’t need to do the estimation in your main workflow system; you just need to keep track of the estimates there.
2. TShirt sizes can be mapped to story points if needed. This helps overcome resistance or speed up the process if people are uncomfortable.
3. You can estimate stories or epics at different levels of resolution. If you want more accurate estimates, you need to invest more time.
4. At the brainstorming stage, you can get something useful with a light touch estimate involving one or two senior technical people.
5. At an operational stage, more precise estimates help adjust the plan, but they also help everyone on the team understand the work and implicitly get their buy-in on the approach to be taken.

Invitation

If you’d like to get early access to my book on improving velocity to get to market faster with your new product, sign up here.

“There were only an estimated two to five thousand humans alive in Africa sixty thousand years ago. We were literally a species on the brink of extinction! And some scientists believe (from studies of carbon-dated cave art, archaeological sites, and human skeletons) that the group that crossed the Red Sea to begin the great migration was a mere one hundred fifty. Only the most innovative survived, carrying with them problem-solving traits that would eventually give rise to our incredible imagination and creativity.” –Marc Sisson

Imagination fed into our uniquely human ability to cooperate flexibly in large numbers. So fast forward to today. Our most valuable and exciting work, particularly in the context of innovation, still relies on our ability to imagine what needs to be done, start, and continuously course correct.

In this case, we’re using imagination to structure and agree how work needs to happen, and to map that to a subjective estimate of effort.

First, we imagine what needs to be built, why it needs to be built, and how it needs to work. Then, we subdivide the big overall vision into lots of little pieces, and divvy it up among a group of people who go execute on the vision. Before they do that, though, these people imagine, analyze, and discuss doing the work involved on each specific piece of the overall vision. They all need to agree how much effort it will take to complete that task. If there are differences of opinion, they should be ironed out up front.

If done successfully, this generate full buy-in and alignment from everyone involved. Even if the end product isn’t a physical thing, this approach works. The benefits of trusting people and harnessing all their energy and imagination far outweigh the inherent risks. It’s already done by tens of thousands of teams around the world already in various digital industries including software.

Relative Cognitive Effort is what we’re imagining.

The key number that is used for tracking this is a measure of how much “cognitive effort” was completed over a predetermined unit of time. Agile and scrum use the concept of a story instead of tasks, in order to help describe complex needs in a narrative form if needed. Usually this includes elements such as: user problem, what’s missing, acceptance criteria for the solution required. Therefore, the unit of measure for the cognitive effort expected to complete a story is called a story point.

Each story is sized in terms of story points. Story points themselves are quite abstract. They relate to the relative complexity of each item. If this task more complex than that one, then it should have more story points. Story points primarily refer to how difficult the team expects a specific task to be.

For example, it’s more precise to track the number of story points completed in the last 2 weeks, than just the raw number of stories completed. As stories can be of different sizes.

Now it’s time for a few disclaimers…

1. Story points are not measures of developer time required.

Cognitive complexity isn’t necessarily the same thing as how time consuming it will be to achieve. For example, a complex story may require a lot of thought to get right, but once you figure out how to do it, it can be a few minor changes in the codebase. Or it could be a relatively simple change that need to be done many times over, which in and of itself increases potential complexity and risk of side effects.

The main purpose of story points is to help communicate–up front–how much effort a given task will require. To have meaning for the team, it should be generated by the team who will actually be doing the work. These estimates can then be used by non-technical decisionmakers to prioritize, order, and plan work accordingly. They can then take into account the amount of effort and trade it off with expected business value for each particular story.

2. Story points related to time are a lagging indicator for team performance.

The key, though, is that story points shouldn’t be derived as 1 story point = half day, so this item will be 3 story points because I expect it will take 1.5 days. This type of analysis can only be done after the fact, and related to entire timeboxes like a 2 week period. Instead, the team should be comparing the story they are estimating to other stories already estimated on the backlog:

• Do you think it will be bigger than story X123? Or smaller?
• What about X124?

The team needs to get together regularly and estimate the relative size of each story, compared to every other story.

This generates a lot of discussion. It takes time. And therefore estimation itself has a very real cost. Some technical people view it as a distraction from “doing the work”. Rightly so.

3. Story Points assume you fix all bugs & address problems as you discover them.

Only new functionality has a story point value associated. This means that you are incentivized to creating new functionality. While discovering and fixing problems takes up time, it doesn’t contribute to the final feature set upon release. Or the value a user will get from the product.

Anything that is a bug or a problem with existing code needs to be logged and addressed as soon as possible, ideally before any new functionality is started, to be certain that anything “done” (where the story points have been credited) is actually done. If you don’t do this, then you will have a lot of story points completed, but you won’t be able to release the product because of the amount of bugs you know about. What’s worse, bugfixing can drag on and on for months, if you delay this until the end. It’s highly unpredictable how long it will take a team to fix all bugs, as each bug can take a few minutes or a few weeks. If you fix bugs immediately, you have a much higher chance of fixing them quickly, as the work is still fresh in the team’s collective memory.

Fixing bugs as soon as they’re discovered is a pretty high bar in terms of team discipline. And a lot will depend on the organizational context where the work happens. Is it really ok to invest 40% more time to deliver stories with all unit testing embedded, and deliver less features that we’re more confident in? Or is the release date more important?

4. One team’s trash is another team’s treasure.

Finally, it’s worth noting that story points themselves will always be team-specific. In other words, a “3” in one team won’t necessarily be equal to a “3” in another team. Each team have their own relative strengths, levels of experience with different technologies, and levels of understanding how to approach a particular technical problem.

Moreover, there are lots of factors which can affect both estimates and comparability. It wouldn’t make sense to compare the story point estimates of a team working on an established legacy code base with a team who is building an initial prototype for a totally new product. Those have very different technical ramifications and “cognitive loads”.

Conversely, you can compare story points over time within one team, as it was the same team who provided the estimates. So you can reason about how long it took to deliver a 3 story point story now vs. six months ago–by the same team only.

Wait, can’t Story Point estimation be gamed?

As a system, story points gamify completing the work. Keen observers sarcastically claim they will just do a task to help the team “score a few points”.

But then again, that’s the idea behind the approach of measuring story points. To draw everyone’s attention to what matters the most: fully specifying, developing, and testing new features as an interdependent delivery team.

Moreover, all of this discussion focuses on capacity and allocation. The key measure of progress (in an agile context) is working software. Or new product features in a non-software context. Not story points completed. If you start to make goals using story points, for example for velocity, you introduce trade-offs usually around quality:

• Should we make it faster or should we make it better?
• Do we have enough time for Refactoring?
• Why not accumulate some Technical Debt to increase our Velocity?

Story points completed are only a proxy for completed features. They come in handy in scenarios where you don’t have a clear user interface to see a features in action. For example, on an infrastructure project with a lot of back-end services, you might not be able to demo much until you have the core

Example: Adding technical scope to an already tight schedule

On a client project, I had a really good architect propose and start a major restructuring of the code base. It was kicked off by his frustration with trying to introduce a small change. A fellow developer tried to add something that should have taken an hour or two, but it took a few days. The architect decided the structure of the project was at fault.

Yet, this refactoring started to go into a few weeks. The majority of the team were blocked on anything important. He was working on an important part of the final deliverable. While the work he was doing was necessary, it would have been good to figure out any elapsed time impact on the overall deliverable, so that it could be coordinated with everyone interested.

As the sprint ended, I proposed we define the work explicitly on the backlog, and estimate it as a team. This way, the architectural work would be a bit more “on the radar”. There were around nine tasks left. The team said the remaining work was comparable across all of them, and collectively decided it was about a 5 story point size per item. So we had added roughly 45 story points of effort.

Knowing that the team was averaging around 20 story points per elapsed week, it became clear we had suddenly added 2 weeks worth of work–without explicitly acknowledging what this might do to the final delivery date. While the architect was quite productive, and claimed he could do it faster, there was still an opportunity cost. He wasn’t working on something else that was important.

In this case, story points helped come up with a realistic impact to schedule that senior stakeholders and sponsors needed to know about. The impact on the initial launch date was material. So the estimation with story points helped provide an “elapsed time” estimate of an otherwise invisible change.

While not perfect, Story Points are primarily a tool for capacity planning, not whip cracking.

So to step back, you can see that story points are a useful abstraction which gets at the core of what everyone cares about: new product features. While subjective, for the same task–as long as it’s well defined–most of the members of a team usually come up with pretty close estimates. It’s kind of surprising at first, but eventually you get used it. And you look forward to differences, because that means there may be something that needs to be discussed or agreed first. That is the primary purpose of story points. As a side effect, it can help get to grips with a much larger backlog. And plan roughly how many teams need to be involved.

However, this approach only works within relatively strict parameters and disclaimers if you want the numbers to mean anything. It is at a level of resolution that proxies progress, but makes external micromanagement difficult. If you want the team to self-manage and self-organize, this is a feature not a bug of the whole approach. Ultimately the core goal is correctly functioning new features. Best not to lose sight of that.

In my last post, I explored the implication of a shift in importance and value of resources. Given increasingly shorter time frames for product life cycles, I think time is an increasingly undervalued resource. Zooming in to a sub-micro level, I think we’re also looking at a paradigm shift with resource allocation within high technology companies too.

Regardless of technology background, all stakeholders usually negotiate around schedule. Time is the least common denominator, from an accountability perspective.

In a traditional project approach, the team would figure out and agree the scope up front. These requirements would be fixed, once they are translated into cost and time estimates. Dates would also be agreed up front. In this case, there is a lot of analysis and scrambling up front, to try to learn and decide everything before knowing it all. In practice, this front-loaded exploration takes time. Regardless of whether the product delivery team is actually working on the product, this elapsed time on the “fuzzy” front end is added to the final delivery date. It takes a lot of time to define and estimate all of the work needed to deliver the scope. And in practice, this backlog will only help us figure out when the project or product is “done”, which in and of itself, has no meaning to clients or salespeople. It is easy to overlook this full-time cost of trying to fix and define all work up front, particularly since the people doing this work can usually get away with not “counting” this time as part of delivery.

And since scope is fixed, and something actually needs to be a pressure release valve, typically one of the bottom three triangles on the left suffer: time, quality, and cost. Then. spending months tracking project progress and with limited client interaction (because it’s not “done” yet) is yet another waste of elapsed time.

There is a way to significantly reduce this waste, by bringing in the client early and maximizing learning in a highly disciplined structure. In an Agile approach, the exact opposite approach is taken. We don’t try to fix scope up front; we fix the rules of engagement up front to allow both business and technical team members to prioritize scope as they go.

Instead, we strictly define business and technical criteria for a project up front, without fully agreeing what the scope is. So, we agree that we will spend up to $185k, quality is ensured with automated testing, and we have 3 months-to deliver something sellable. We may only deliver 1 feature, but if it’s a valuable feature then clients would pay for it. If all of these are unambiguous, then the product team itself can prioritize scope operationally based on what it learns from clients. For all types of products, ultimately the clients and the market will decide to buy whatever is being built.

What’s fundamentally different here? Scope is defined by a series of operational or tactical decisions by the product team, not strategic ones defined externally to them. Senior business stakeholders shouldn’t need to follow and know the technical details of what’s in a product and what part of the project is “done”. It’s getting down into too much detail and communicating a lack of trust in judgement to a highly paid team of technical experts they meticulously recruit and train. It also undermines a sense of outcome ownership by the team. Because everything about their work is defined exogenously and just dropped on them.

What is the total cost of having a waterfall wrapper around agile teams?

Clearly efforts need to be coordinated across an organisation. Trying to use detailed waterfall-style up front planning will cost you elapsed time and may cost you the market opportunity you’ve identified. It’s better to have shared access to backlogs and agile’s drive to deliver potentially shippable software on a short cadence. Because you know you can use anything that is done by another team. And you can estimate or prioritize based on an open discussion among teams.