Why building for the entire market bloats timeframes, and what to do instead

In High Output Management by Andy Grove, Intel's founding CEO, Grove suggests that Intel operated in an environment where they needed to manufacture units to a market forecast. From the beginning in the 1960s, they didn't have the luxury of selling up front and building exactly what was sold. Nowadays, this is pretty much the defacto environment for product development. Even in the case of software, where there is no manufacturing or reproduction cost, timing the scope to match demand is a core component of a software company's success.

In order to plan the release of a product, you need a clear scope of what product development needs to happen first. This includes breaking down tasks, estimating them, and then mapping the specific features to expected customer value. This way you come up with a set of features that need to be created, in order to release the product (or release it again).

How this typically plays out in practice

In practice once this is agreed, new ideas come up. New stakeholders propose specific changes or additions to that original scope. You might even want to try reaching more prospects in a related segment.

1. Add a bit more scope: The natural impulse-in this environment- is for product development teams to simply add scope to the list of stories or tasks which were already agreed.

Vicious feedback loop for scope

2. Push the release back a bit: As soon as they add another feature, this effectively means more work needs to be done. So the effective date when everything will be done is pushed back. Usually this means the estimated completion date needs to be adjusted, even if this isn't explicitly acknowledged by the team.

3. Delay market feedback a bit: If the release date is moved back, the team delays getting market feedback. Depending on the size of the feature, it might be a few days in a software context. Or a few weeks.

4. Reduce probability sales: of If the feedback is delayed, you reduce the team's confidence that the product will sell. The less feedback you have, the lower the probability of hitting your sales forecast when you ultimately do release. So your probability-weighted revenue goes down, the later you release. In a sales context, "money follows speed" is common knowledge. Being able to close a deal quickly is really important, because if you don't, it's likely the customer will change their mind. And finally, if you are less certain about your sales forecast, this typically influences your overall confidence level in the product. And one of the most natural things done in this case is too...add a bit more scope.

Deja vu. The cycle repeats.

Paradoxically, the more scope you add, the lower the chances of market success of the release. Because you're innovating in a vacuum/ivory tower/echo chamber/<insert favorite metaphor here>. Even though you think you are improving your product's chances. Having too many features is overwhelming for prospects and difficult to communicate for you. The paradox of choice kicks in.

Also, if you delay the release date, you are likely to struggle to make sales until that date. There are "forward contracts" or "letters of intent", however customers will only go for something like this if they are highly motivated to get your solution. It also adds a layer of complexity and obviously a delay, thus making it harder to sell the product.

Implementation notes for startups

In the startup case, you need to get enough scope to attract early adopters in Moore's technology adoption curve. This will typically be one or a handful of related features which address a core need of theirs and which they can't address anywhere else.

Source: Harvard Innovation Lab

The idea is that you need enough scope to go after a narrow group of people, just to get started and out the door. Trying to build enough scope for the entire market will mean you'll never actually move ahead with your business. Because you need to launch it first. The sooner you get it out there, the better for you.

Once you have nailed that first segment, you expand to adjacent segments. You modify the product to appeal to the adjacent segments. And then go sell to them. Do this incrementally, so that you have the benefit of revenues from the first customers. And confidence from initial market success.

Implementation notes for established companies

The above is true for larger companies; however, they have internal operational challenges to overcome also. In particular each of the 4 parts of the circle are often represented by different department heads. Each has his or her own agenda to push.

And while each incremental change might seem to make sense in the short term, the overall effect is the delay of a release. And no one is individually responsible for it.

source: Randy Olson | the operational usefulness of pie charts

Moreover, in a large company environment, go-to-market decisions are often made based on overall market size. While this is useful to think through e.g. positioning of a new product, thinking in terms of top-down market pie charts doesn't translate into a plan to enter the market. Different slices of the pie will want different features, with some overlap across the market.

It's ok to plan to enter the entire market eventually, but it's smarter to prove the approach works on a small corner of the market--before you expand outwards.

Acknowledge it's uncomfortable, and just do it anyway

I get it. It feels unnatural to be selling something that isn't perfect. It's easy to succumb to a fear of rejection, and just put off the prospect of releasing the product for as long as you can. I've done it in the past on my own dime. I hear the mechanism at play when mentoring founders. I see the dynamics play out in larger companies every day. Every product team with an ounce of humanity is susceptible to this.

Focus on a small subset of customers with a similar set of needs, and only build the scope that they need. Keep it laser focussed. And get it out there, even if it's not perfect. Especially in a business context, if your product addresses the core need they have, they will be happy.

Ultimately, fear of rejection just a bias that prevents you from learning what you need to know to make your new product a success. If necessary, speak to customers about their problems only--and don't show them your solution right away. Most people are happy to gripe to a friendly ear, especially if it's about something they care about. Don't make promises you don't expect to keep. But start speaking with flesh and blood customers right from the beginning.

How to resource projects and products--optimizing for elapsed time, motivated teams, and budget

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.

standard approach: agile in a waterfall wrapper

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.

start work sooner, ship more, and incorporate client feedback sooner

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.

How to optimize for your tech company's scarcest resource

Back in the 13th century, Princess Kinga of Hungary received an engagement ring from Duke Boleslaw of Poland. When discussing her dowry with her father, instead of just offering the usual "gold and money" which was relatively common in those situations, Kinga asked her father to gift a salt mine. Salt was a scarce resource and the only way to conserve food at the time, so it inherently had a lot value.

When gifted the largest mine in the Austro-Hungarian empire ( Maramureș ), she was worried that the whole mine couldn't be moved to Poland and therefore she'd still be under the thumb of her parents. So after significant thought and even prayer, she dropped the engagement ring down the mine's shaft.

Kinga and her ring | Source: Wikipedia

Later, when princess Kinga was in transit to Cracow for her first meeting, she took a handful of Hungarian miners with her. She ordered her party to stop around the Wieliczka area. And asked them to start digging. They hit a rock and said they can't go any further. Kinga asked that the rock be crushed open. It turned out that it was essentially rock salt, and her engagement ring was found inside.

While the truth behind this origin story has been lost in the mists of time, a mineral repository was discovered. What did happen as a result? Huge economic growth in the region. The cities in the country went from being built in wood with wooden forts to brick and mortar and castles. Largely financed by salt mine profits.

Over the longer term, the price of salt fell. With it, the economics importance of the salt mine to the country's treasury. And other resources became important to economic growth. A paradigm shift occurred. And the medieval salt warlords drifted into irrelevance and obscurity.

How is that relevant today?

The closest analogue today is probably the petrochemical industry that fuels the Middle East's economic engine. As long as the price of oil stays high, that whole region has a disproportionate amount of wealth generated. These profits are reinvested in other parts of the economy local and global economy. And the prospect of peak oil would seem to give the sheikhs high hopes for even higher prices of oil and oil-based products over the longer term.

Source: thenational.ae

Yet already there are longer term trends at play which are likely to disrupt this. Looking at companies like Tesla, Elon is betting that the solar energy will replace oil as a source of energy. And the bottleneck will move from generation to storage and possibly transport. At that point, the price of lithium and other minerals needed to build batteries is likely to enter into a longer term bull market.

So, just because oil is valuable now, doesn't mean it will always be valuable. If Elon's strategic hypothesis proves to be right, the oil magnate sheikhs will be out of luck too. Nobody really knows how this will play out. But I'd be willing to bet the oil, gas, and automotive industries will look different in 50 years than they did 50 years ago.

It's easy to overlook one particular resource

Strategic resources or "factors of production" to consider according to classical economics:

• Land
• Labor
• Capital
• Enterprise/Entrepreneurship
• Technology
• Natural resources

Usually the current strategic approach is to think about finding the optimal balance in the resources above for your particular industry. The goal is to maximize wealth in the long run.

Resource levelling | Source: Wikipedia

In the case of software, tech decision-makers usually spend their time focus on labor-sometimes called human capital-as many skills tend be hard to find where it actually matters. Once you recruit and train the right people, then it's a question of making sure they have everything they need to do their jobs. Especially being clear on what needs to be built or modified. But also the other factors in frameworks like Gallup's 12 Questions.

In the executive offices or founder's garages, the discussion extends to capital and entrepreneurship. Knowing where and how to raise budget (capital) and how to allocate it to the biggest opportunities (entrepreneurship) is an ongoing effort.

Over time, a successful company will tend to accumulate technology assets which are unique and which have value. Which make them uniquely capable of executing a business model that beats comparable companies in the same industry.All of these play out over time.

Time is considered an obvious given. Really?

So in addition to the actual resources you need, you need to figure out optimal timing of when to inject in the resources to improve your company's business outcomes. In other words, most companies focus on finding the optimal balance of resources right now-relative to one another. Which is completely reasonable given the current paradigm.

What I'm exploring at the moment...what if time itself is a resource and input? In other words, instead of only thinking about how output changes right now if you add or remove people, what about allowing yourself to think about varying time.

• How would you change your approach if you had year runway to release something?
• How would you change allocations if you had one week before a client wanted to use your product?
• How much are you actually affected by time consuming efforts like training up a new recruit?
• How much time does the team spend on "hardening" and bugfixing before a release in a big batch?
• When will your clients or your actually need to have the product and how does that look in relation to competitor's actions?

These somewhat philosophical questions, if thought through, could have quite significant practical implications on most projects. Because time is money, too. If you have a detailed plan to build a product and prospects who need what you're building, you are effectively paying an economic cost of delay, as per Don Reinertsen's work, for each day the product isn't ready to ship. And if you want to allocate resources rationally, you should be taking into account this cost.

Tech product life cycles are shortening. Company lifetimes are shortening. Industry lifetimes are shortening. At which point does time itself become too valuable of a resource to ignore, when in the throes of pursuing an opportunity?

How to befriend time when you're in a hurry

Miyamoto Musashi was a legendary renaissance samurai poet and painter. He invented the technique of fencing with two swords. According to legend, he won over 60 sword fight duels. He was so talented, that he killed an adult samurai with a wooden sword at the age of 13. He single-handedly fought of an ambush wrought by a samurai school. Personally, he fought in 6 wars. 

Musashi Miyamoto on velocity

These Rambo-esque legends weren't his greatest contribution, though. On his deathbed, he penned a treatise on strategy called "A Book of Five Rings". As he had the ability to kill of so many opponents in duels (i.e. being on the right side of 60 duels), he became a master of the psychology of battle strategy. The book contains his insights into how he thought about this process.

“Whatever the way, the master of strategy does not appear fast….Of course, slowness is bad. Really skillful people never get out of time, and are always deliberate, and never appear busy.” Some people can cover 120 miles a day without breaking a sweat. Others will look tired within a minute of starting to run. 

What's really at stake here?

How you feel about urgency and speed is a reflection of your habits in a personal context. If you have bad time management habits personally, then of course you will feel discomfort about time going by. And the opposite is also true. If you have good habits and you live in accordance with your priorities, you look forward to time passing. It works in your favor.

Photographer: Form | Source: Unsplash | Aiming for the above with my stretching routine

I can definitely see this when I do my daily stretching routine. Even though I might not be happy with the point where I started, if I do my stretches every day, my flexibility increases. And I see progress over time. So I look forwards to time passing, because if I have increasingly better results.

This observation is fractal. In a professional context, it's about the quality of your company's systems. If you have well thought through and optimized systems, you look forwards to achieving your goals. Time feels like it's on your side. The competition isn't as important as the stopwatch. Like in a road race. If you have poor systems, you're constantly harried and monitoring and firefighting. And there's no time to do anything longer term.

Photographer: Robert Anasch | Source: Unsplash | Time is on your side if your company has well thought out systems.

If I can extend the metaphor a bit to building shareholder value, particularly in software companies or in knowledge work: "Wealth is built with time as an asset, not as a liability". 

How to determine if systemic factors slow down your teams' velocity

Last week, I pulled out the critical thing that Steve Jobs did, upon returning to an Apple computer with a sagging stock price. He went after a major systemic factor that was holding back release dates: too many priorities. If you are really going after top performance, you need to look at all factors, including the global ones.

Local or global maximum?

Photographer: samsommer | Source: Unsplash

When standing on the top of a hill, every way you look is down. It's the definition of a maximum. The thing is, though, you might not be standing on the highest possible hill or mountain in the area. And it's difficult to know that. You typically won't see mount Everest unless if you are in the Himalayas.

maximizing velocity: every way you look is down

The same is true when you are maximizing velocity, and looking for the top of the parabola. There is a lot you can try to improve a team's velocity. But it's worth checking whether the team is being held back by systemic factors that you can't see from where you are. Or is it really just a team-specific challenge.

It's quite likely you don't even see the potential global maximum, because of pre-existing company culture and procedures, particularly in a larger stable company. It's worth trying to improve velocity locally, at the level of one team. But also keep in mind that you might be climbing the wrong hill. The higher one will be start with improving the context in which the team operates. A low velocity may simply be a reflection of a difficult culture and context in which the team operates.

local vs global maximums: where is your product development really?

Three Examples of Systemic Factors

Before we deep dive into improving team-specific output within each team, here are three examples of systemic factors I've seen at client sites that slow down team velocity:

1. Resource Thrashing

2. Too many chiefs

3. Communication overhead

Let's start at the top, shall we?

1. Resource Thrashing

If your true priorities aren't clear, this impacts you on many levels. Before getting to the somewhat obvious operational impact, consider the revenue impact first. Yes, revenue!

source: Booz, Allen, Hamilton, Harvard Business Review

According to "Stop Chasing Too Many Priorities" by Paul Leinwand and Cesare Mainardi in the Harvard Business Review, too many operational priorities correlates with a given company's ability to outperform its peers in terms of revenue. Having too many "#1 priorities" will reduce revenue potential. It will be harder to communicate the vision to both customers and employees, as Jobs noted above. Also harder to execute.

For example, one common trap is just to list everything you are doing as a priority. Yes, every cost and effort needs to have a goal and be justified. But this approach muddles what exactly needs to change. Because everything we are working on is a priority. It is easier to sell to existing employees and shareholders, but it doesn't really lay the groundwork for anything to change.

Operationally, Steve Jobs focus on the 4 quadrants solved what I call the "denominator problem" from an operational standpoint:

people per product = people/nr of products or projects

The large the number of "buckets" you need to fill, the higher the denominator. The higher the denominator, the less resources you have to succeed with each product. New or existing.

This is the true cost of lack of focus. Because if you are under-resourcing your product teams, you are effectively setting them up for failure and yourself up for disappointment as a decision-maker.

Signs of this would include:

• Heavy reliance on traditional project management (waterfall): as there are lots of resource conflicts, you need a caste of professionals to manage this, each with their own specialty. Which adds more cost. Note that they don't actually contribute to the work that needs to be done directly.
• partial employee allocations: For example, allocating 5 people at 20% will mean that all 5 people will spend most of their time in status meetings and unable to actually deliver anything. But you have the slot fully allocated, right?
• shifting team structures: If needs are constantly changing due to thrashing, then there is constant complexity around what needs to be done, who needs to do it, and by when. So you're spending a lot of time figuring out how to achieve new goal with the limited resources you have and who you can nab from elsewhere.

2. Too many chiefs

For anyone who remembers high school physics, there was one important distinction between velocity and speed--as my friend Andy Wilkin recently pointed out. Velocity had an implied direction. One direction.

Velocity measures speed in a specific direction

If each manager pulls in their own direction, they collectively turn velocity into speed. A low speed. And effectively no clear direction.

There is a value in having specialized managers which look after shared company concerns. Ones which cut across multiple products. For example, a function like DevOps or a shared database infrastructure. But then you also have functional managers, like QA. And project or delivery managers who are on the hook for getting the team to ship. And geographic managers who keep a close tab on staff in remote offices, possibly because they can charge out the time. And you end up in a situation with a lot of managers who mean well, who want to stay informed, but they don't really contribute to the work which needs to be done.

This is a systemic problem of unclear goals, covered up by having layers of people who are responsible for slices of what needs to be delivered. Here are a few metrics you can track:

• cost of going in the wrong direction: Often a side effect of having too many stakeholders, you can end up building things which sound good to internal decisionmakers or committees, but which customers could care less about. In other words, the "voice of senior manager" booms louder than the voice of the customer. total cost = nr man months * monthly burn rate
• cost of oversight crowds out budget for people actually doing the work: a side effect of having so many managers is that you don't have enough money left over to hire competent people to do the work. Managers are expensive and, ultimately, they aren't really required to accomplish the goal. Just to structure the work and monitor progress. Some of that is necessary, but ideally it's done by people doing the work with a high level of trust and a minimum level of oversight.
• ratio of stakeholders to team members at meetings: This originated as a snarky observation on my part. Doesn't make it less true. For operational meetings, such as a development team standup, if most of the people attending say they are "just listening today", that means they aren't adding value and they are taking up others' time. To be followed up by more meetings with other stakeholders and managers to discuss what is happening at the standup. In practice, there is a high financial cost to all of this, and this ratio is a good proxy for that cost, even if employees don't know who makes how much.

3. Communication overhead

One of the older pearls of wisdom that have been floating around the software industry is: "9 mothers won't be able to deliver one baby in 1 month.

Your ability to add people on to a project will typically be constrained by the structure of what you're building. But also by sheer communication issues. Before anyone can contribute to a project, they need to have enough context to be ableto do so. That is harder than it seems. For one, they need to know how their bit contributes to the overall vision. So they have to understand enough of the big picture, to locate where their addition should go. For another, they need to know who knows what. Who to ask specific questions.

Much of this accumulates based on natural interaction patterns in groups of people. Each person will need to relate with every other, even the junior people to the senior people. So every important messages needs to go out to everyone. And also needs to be understood by everyone.

Common patterns to make this "work":

• hub and spoke pattern, where the manager is the source for all decisions and communication. Typically, this results in the manager's time being a bottleneck, and most of the team sitting around and waiting for instructions. And overall progress is slow.
• peer-to-peer pattern, or the self organizing one. This is much more effective and immediate, particularly if there are differences of experience, skills, or knowledge among team members. but this is often difficult to scale up. Each additional node added to a network of peers adds increasingly higher communication requirements. A network of this type has n! connections, so 25 peers in a flat network have 25! connections or 1.55 * 10^25 connections.

In practice these sheer numbers are combined with either inexperienced or offshored staffers or partial allocations of busy people who can't be 100% spared. For the first, it's clear why they struggle to contribute (at least without direct access to managers and mentors who are too overstretched to help). For the second, if you have a senior BA allocated at 20% to a project, most of that time will be attending status and planning meetings just so that she has context. So there is almost no time available to do any work.

So in short, for discovery intensive work like new product development, you are setting yourself up for difficulty if you put too many people on the product too.

Wait, so how do you get a globally optimal outcome if you can't add either staffers or managers?

Beyond a certain point, it doesn't make sense to add more. You will see it in your output metrics. And ideally that output goes in front of customers or prospects frequently (with commercial intent of course).

Small, highly experienced teams who know what they are doing. And with direct access to customers, to ensure they are building something customers care about. These people are probably on your team already. Get rid of everyone else, and give these team members the space to do their thing.

If you want to increase learning and speed, add more independent teams with the same characteristics. But don't make one team too large in the hopes that the software factory will output more web screens and database tables per month. Because either it won't or it will, and in both cases, you can end up disappointed.

Note that this is the exact opposite of what large, efficient and established companies are used to doing. Being deliberate, effective and thoughtful will leadyou down a much better path.

The one thing Steve Jobs did that turned around Apple

After a nasty battle with Apple shareholders, Steve Jobs, then the original founding CEO, was ousted. He went on to create NeXt computers (later acquired by Disney). In the meantime, Apple drifted as a company. It proliferated product lines. Lost focus. And the share price entered a death spiral phase. A few years later in 1997, he was recruited back to save the company from very poor public share price performance.

"Saint Steve" at Macworld 1998

When we got to the company a year ago, there were a lot of products. There were 15 product platforms and a zillion variants of each one. I couldn't even figure this out myself. After about three weeks. I said, "how are we gonna explain this to others, when we don't even know which products to recommend to our friends?"

In this keynote at 1998 Macworld, he announced early successes, such as a 3rd consecutive profitable quarter. In my opinion, one of the most powerful parts of his talk was the following grid:

The 4 apple quadrants, source: Apple

In effect, after a strategic review of all 15+ product lines, Jobs decided that these four were the only products worth focusing on. Consumer was aimed at consumers and education. Pro was aimed at publishing and design. Everything else was shut down. Here was his rationale:

As a matter of fact, if we only get four, we could put the A-Team on every single one of them. And if we only have four, we could turn them all every nine months instead of every 18 months. And if we only had, four we could be working on the next generation or two of each one, as we're introducing the first generation. So that's what we decided to do: to focus on four great products. And the first one that we introduced of course was the Desktop Pro product.

Notice that the main practical reason Steve Jobs cited for this change is the reduced product release time, or cycle time. Or low velocity in agile terms. He could release a lot of resources. Focus them just on these 4 great products. And get out of the bureaucratic quagmire that was holding the company back.

This was the kind of "zero-based thinking" decision that a hired gun CEO would be afraid to make, but a founding CEO could find the courage to do. To implement a company redesign and rethinking from first principles, rather than just tinkering around the edges. Steve Jobs knew what life before Apple was like, because he was there. And he already had a successful "go" at building the company. So it didn't take much to identify that the company needed to be slimmed down and focussed in order to become stronger.

Of course, there was uproar amongst developers with vested interests in existing product lines. To a lesser extent, among clients of the cancelled products. But this marked the beginning of Apple's long climb to a corporate icon and stock market darling.

How to analyze the impact of velocity on your release date

While "agilefall" has many well documented downsides, I've found a counterintuitive bright side to the following aspect of it: "We have a product backlog with priorities, but we start working on a release with a long list of features already committed to the business."

In this case, we have a pretty detailed view of scope as well as developer estimates of complexity. There is a lot of data to crunch.

From a pure business perspective, the key variable that matters is the release date. Dates have a significant implication for the rollout across the company and existing client base. Here's a few business reasons why:

• marketing and sales plans need to be made (since they're separate "workstreams")
• overall costs and ROI of the program changes
• coordination and resources need to be shared/reassigned with other internal teams

And most importantly, the date is completely non-technical. Anyone who graduated from primary school can understand it. So the nice thing is that the release dates help focus the discussion on what matters, while only needing to go into a minimal amount of technical detail.

Making the relatively liberal assumption that scope will not change, it's possible to generate a pretty decent forecast of the date.

Moreover, it's possible to model the impact of a higher or lower average future velocity on release dates. In other words, if there is a need for a plan, you can make the entire plan using the following approach:

• dependent variables: incremental release dates
• independent variable: hypothetical velocity

And then look at what happens to the release dates as you vary velocity.

Photographer: Waldemar Brandt | Source: Unsplash

The entire plan fees like an accordion which can be pulled out or pushed in, depending on your assumptions about velocity. If velocity is high, the releases are close together. If it's low, they're quite spread apart.

Here's an example of a quick model I did by exporting my data from Jira and using Excel's scenario manager:

By varying that one number and holding scope & team constant, the dates which are hit for each release change significantly. Let's get into how to do it for yourself first.

Case Study

We've defined, broken out and even estimated scope for this program. It contains hundreds of stories (tasks really) related to the delivery of a big infrastructure. All of this is being tracked using a standard agile tool called Jira, with relevant details attached to each story.

Here's the type of analysis we'll need to do as an interim step:

The unit of effort measurement here is the "Story Point", an abstract measure of relative complexity of a piece of work. This is quite common in agile circles, to help give the delivery team a safe way to discuss and size the work, without biasing it towards what stakeholders "want to hear" and to help them "save face" if a complex task takes a long time (even though it wouldn't necessarily be obvious to a non-technical person).

The key "number behind the number" here is the velocity. It's expressed as the story points completed per unit of time. In this case: one week. Velocity tracks increments of fully complete work that has been specified, developed, checked, and signed off.

If we estimate the story points for each task up front, it's possible to observe velocity as the team works on the scope. Basically, you see performance as the change in that number over time.

On this project, we are tracking velocity in weekly increments. This gives us more data points and increases our confidence in the numbers faster than if we were calculating it on a monthly basis for example. More observations, higher confidence--statistically speaking.

In the example above, the actual team doing the work has been delivering at a rate of 27 story points per week. But what if the average future velocity was higher or lower than that?

Step 1: Pull out the scope sizes from Jira

For me, the fastest way to get to the real numbers is to pull up reports. At the moment, most of the modelling we are doing is based on the Jira versions (fixVersion). Previously, I've used Jira epics using different reports.

reports on left sidebar

Then choose the version or epic report:

here in a drop-down

And finally pull out the actual story points completed in the version:

And incomplete:

And finally the number (count) of unestimated stories, as delivery teams tend to push back on spending too much time estimating rather than doing the work:

Remember to exclude any known bugs as these will typically have 0 story points anyway, and use your judgement for other issues.

Type these into Excel (yay data entry!):

typing in numbers from that report

Step 2: Create a key assumptions section

Hah! The 'A' word.

In your spreadsheet, put in an assumed value for the unestimated stories as the average size (in story points) of issues and the expected velocity for your delivery teams:

Step 3: Fill out the remaining formulas to estimate your release date

Essentially, once we have the estimated total scope and velocity, it's just a matter of dividing the former by the latter, to generate the number of weeks of work remaining:

Here are the actual excel formulas I used to generate the magic date:

Step 4: Rinse and repeat for remaining versions on your backlog

Essentially, you are holding the team, scope, and velocity constant and using your estimates to figure out when you will be ready to release each version. This is, of course, based on what you know now, which is subject to change. :)

The formulas are more or less the same throughout the versions. In this case, I'm assuming the team will finish version 1 and move immediately to working on version 2, so column I needed some adjustment.

Step 5: Kick up the What If analysis using Excel's scenario planner

First move your cursor to the variable you want to model, in this case your velocity assumption:

This is the "independent" variable in statistical terms that you want to vary, in order to see how it affect the dependent variables you care about: the completion dates.

This is probably one of Excel's most powerful non-quantitative easter eggs. While allowing you to vary individual values, you can extrapolate impacts that reach far beyond what is possible (for most humans) intuitively.

Within there, choose the Scenario Manager, and the following comes up:

Click add, and then use the cell you selected previously as the main variable to vary:

You can call the scenario whatever you want that has business meaning to you and your company. Then enter a value for this scenario in the next prompt:

And then do this again for a few other scenarios. In this case, I created a higher velocity at 60 and a lower velocity at 20. This range is so wide, simply because I have no data to go on, so I'd like to explore the optimistic and the pessimistic scenarios.

When you have all of this done, and the scenario manager is correctly set up, click on summary:

Based on that, Excel asks you which cells in the sheet you actually care about when you are varying scenarios (the dependent variables):

And after you hit OK, Excel hangs for a bit and returns with the following magical table:

This gives you a sense of how different average velocities will affect your delivery dates and plan. It gives you a qualitative feel for what would happen anywhere within your range, too, by looking at the outer boundaries. It's enough for you to take and present to stakeholders in terms of what the velocity number actually means, what tradeoffs might need to be adjusted, what resources added, and all of the other things which might need to be changed to influence velocity.

Of course, you'd want to make it a bit prettier and clarify what these things mean:

Ok, now you're talkin'! So we are finally at the velocity accordion state. Depending on what velocity we end up getting out of the team, these are the dates we expect to hit for each incremental release. As you can see, the difference between doing the entire scope at a velocity of 20 vs 60 is over an entire year out. Even if all of the details of what is delivered are exactly the same, done in exactly the same order, by exactly the same people, there more than an entire year of difference in the final release.

In other words, detailed planning this far into the future should not include commitments to dates--even if you do have your entire backlog defined and specified and you're hoping it's "accurate".

Figuring out your velocity and how to increase it has much greater business value (bringing release dates in) rather than trying to specify and estimate everything up front to the utmost detail.

This is particularly true in a corporate context with large budgets and a need for "saving face" in case the product isn't fully perfect before it's even discussed with prospects or existing customers. It's much better to commit to small increments of work that are then tied to specific customers needs, as that is the shortest path to revenue in an enterprise sales environment. On top of that, focus on managing velocity and not detailed planning, as that will get your product out there faster. Ultimately your customers could care less how detailed your release plan is; they just want a product that addresses their needs.

Keep following the story

I'm writing a book on adaptive innovation. If you'd like to know more, ask questions, or just be notified when it's out, enter your details over here.