Tinned Fruit

Question: What else do you get excited about?

Fri, 17 May 2019 00:00:00 +0100

I have a question for you this week*. Here it is:

Apart from front-end development, what other aspects of technology and the web are you deeply interested in? Why?

OK, strictly speaking that’s two questions. Let’s call it a two-part question and be done with it.

I’d love to know what other topics front-end developers spend their time thinking about, so please hit reply and let me know.

All the best,

– Jim

* - This may or may not be due to being busy with other work.

The developer-driven economic stack

Fri, 10 May 2019 00:00:00 +0100

Sometime around 2008 or 2009, I was dabbling in Ruby on Rails development in my spare time as a distraction from my front end contracting work. Someone suggested I take a look at Heroku, a new(ish) tool for hosting and deploying Rack-based apps (like Rails).

I was sucked in. Heroku made it really easy to deploy toy apps into a production environment, and it was free. For a front-end dev with extremely limited system administration chops, this was indistinguishable from magic. In the following months I shipped a procession of terrible side projects.

None of those projects were good; nor was I motivated to try to get people to use them. But the point was that Heroku had dismantled some large barriers to entry for people like me who get nervous about hardware, servers, configuration, databases and so on. The Platform-as-a-service (PaaS) market was born*.

The stratospheric rise of the PaaS market reflects a wider phenomenon: recognising and fostering the decision-making power of hands-on developers.

The developer-driven economy is nothing new of course. Venture capitalists love to chat about the importance of understanding the developer market and using developers as an entry point to very big markets.

What’s newer is that developer tools with a front-end focus are now getting in on the act too. If you think frameworks like React and Angular are just mature open source projects, you need to take a look at how they’re marketed, and how much money Facebook and Google are willing to spend on these projects. They’re not just after mindshare. There’s a long-term strategy behind sponsoring open source projects internally in this way. Tobie Langel writes frequently about the strategic benefits of this on his mailing list.

And then there are modern serverless PaaS platforms like Zeit’s Now, aimed squarely at full-stack and front-end developers, and built with their own open source software. You can expect Zeit and similar companies to become increasingly influential in the next few years.

While using a suite of AWS, Google Cloud or Microsoft Azure services is becoming the new default for enterprise applications, there is a place for highly-targeted tools at the next level up the stack for smaller organisations. While you lose some flexibility, there are big gains to be made in paying slightly more for a set of well-developed abstractions that allow smaller teams to move more quickly and with fewer specialists.

The same could be said for the big front-end frameworks. They are very deliberately developer-friendly abstractions, sometimes at the cost of raw performance or deep control. Their popularity demonstrates that teams are willing to make these kinds of economic trade-off.

For me, the web platform itself needs to take the developer-driven economy into account. Using some web platform APIs directly often feels similar to using AWS services directly. That’s why there are popularly libraries for abstracting common use cases, e.g. offline caching using service workers (Workbox), or managing DOM updates efficiently (ReactDOM, Svelte, Elm, etc, etc).

Sometimes cowpaths are paved of course. ES6 was partly a cowpath-paving exercise. But so are the Fetch API, portals and various DOM methods (because of jQuery). The demand for these was created by developers.

These paved cowpaths also end up creating further opportunities for developers to build on top of the platform, of course. WebAssembly will no doubt feed much of this innovation over the next few years. It’s going to be fun to watch.

All of this rambling is to say: keep in mind the layers of the stack at which you are operating as a team, and how your chosen tools fit into this picture. Choosing a framework, a PaaS service or even a smaller library is both an economic and socio-technical decision that impacts the value chain in your organisation. No pressure then!

All the best,

– Jim

P.S. To be fair, Heroku was not the first PaaS. That’s credited to Fotango’s Zimki. I recommend reading Simon Wardley’s account of it’s creation, part of his online book on Wardley Mapping. Wardley mapping can really help to understand how value is realised through a value-chain, and how you might make strategic changes to it (similar to the ‘stack’ I’ve been waffling about above).

Mura → Muri → Muda

Fri, 26 Apr 2019 00:00:00 +0100

“I didn’t want to do this, but to make the numbers for our investors we’re all going to have to give extra for the next few months. I’d really appreciate all your commitment and hard work on getting us over the line.”

Ugh. Crunch Time.

We’ve all been there. The bosses gather everyone together and tell the team (without really saying so) that they expect us to work long hours to hit a deadline or the targets set by investors.

Early in my career I used to accept crunch time as part-and-parcel of working in tech. A young urban male with no responsibilities can easily accommodate short bursts of long work hours. But for everyone else, and for sustained periods, it’s just not a winning tactic. For anyone involved.

In a 2006 post, lean manufacturing guru Jim Womack neatly describes why.

The Toyota Production System defines three areas of waste:

Muda - waste. Any activity that consumes resources without directly creating value for the customer. Muda is further distinguished by necessary activities that can’t easily be removed and those that can be addressed through kaizen (continuous improvement), of which there are seven types.
Mura - unevenness in operation. Jim Womack gives an example of increases in automobile production that are not related to any increase in customer demand, but more about ‘making the numbers’ for the quarter.
Muri - overburdening equipment or operators. In lean manufacturing, the consequences of running equipment harder or longer than their designs allow are well known. Similarly, overburdening people with long hours or unrealistic expectations of speed holds consequences that are also a source of waste in the system.

Womack’s argument is that lean manufacturing practitioners tend to focus their initial improvement efforts on eliminating the seven types of Muda:

Transportation (inefficient movement of products and supplies)
Inventory (Storing too many or too few products or supplies)
Motion (Unneeded effort by workers or machines)
Waiting (for upstream work to be completed)
Over-processing (putting more work in than necessary to meet expectations)
Overproduction (creating too many products or adding characteristics that aren’t valued)
Defects (issues that cause products to fall short of expectations)

You should be able to see how each of these apply just as much to software development as they do to manufacturing.

But Womack argues that many waste problems are a result of problems of Mura (unevenness) and Muri (overburdening), and so it’s better to focus improvement efforts there first.

Crunch Time is an example of this.

Crunch time usually arises because there is a perceived need to deliver a large chunk of value in one go. There’s usually a deadline to go with it. This is an example of Mura - an unevenness in the delivery of value over time.

Crunching in order to meet these expectations is Muri. It’s an overburdening of workers and processes. Too often, the expectation is that it’s possible to just turn up a speed dial with no consequences.

But in reality, overburdening leads workers to cut corners, force value through the system too quickly, and make mistakes. In other words, Muda. Take another look at the seven types of Muda above and mentally tick off the ones that you’ve made in the past during crunch time. I counted four. Counter-intuitively, it’s even possible to over-process and over-produce in crunch time, even though we would expect the opposite to happen. Can you see why?

Unfortunately, as Womack states, fixing this “will be hard work and will require courage because it will often require you to rethink longstanding sales, management, and accounting practices that create the Mura and Muri.”

In other words, it’s essentially impossible to fix once crunch time is already on you. It’s something that needs to be anticipated in advance, and the fixes are mostly cultural.

All the best,

– Jim

I accidentally a product manager

Fri, 19 Apr 2019 00:00:00 +0100

Within the front end development community, there is a relentless focus on cutting edge technology and the technical expertise that goes along with it. But in truth this is only a part of the role of senior and lead front end devs. That’s the basic premise behind this mailing list - I want to help UI developers with the rest of their job beyond the purely technical.

Depending on circumstances, front end developers can easily find themselves taking on other roles and responsibilities in software development teams. For example, it’s easy enough to find that you’ve become a reluctant scrum master.

But it’s also common for developers to take on some testing, system administration, line management, design, user research, customer support or IT responsibilities, depending on circumstances what kind of work you’re drawn towards.

For me, accidental product management work has appeared on my responsibilities list time and again. In the dim and distant past, this was because product management wasn’t a distinct job role unto itself. It was (and still is for many) something that’s handled collectively by the team in some way (however effectively).

The clearest example of when I became a product manager by accident was when I made the case for building an internal-only REST API at a consumer product company. Doing this would allow us to move our product beyond the desktop-only web application we currently had to a more flexible suite of products across mobile, desktop and other platforms. As a reward for my vociferous lobbying, I was handed the job of leading the team to design and build the API.

At first, I imagined that the role would involve learning about RESTful API design and then applying those principles to our existing product, which I already knew well. Simple!

It turns out that it’s relatively easy to design the basic structure of a REST API, but another matter altogether to design a user-centred API to reflect an existing product, taking into account pragmatic concerns around rollout, adoption, performance, availability, scalability, monitoring, change management, security, and all the other concerns.

It wasn’t the simple matter of mapping existing data and manipulations of those data to a RESTful format that I had imagined.

REST APIs have end users, even if those users are internal to the company only. But our team did not have a dedicated product manager. They were mostly focused on direct consumer-facing functionality, and I wasn’t part of their team.

It took me far too long to realise that I was now a product manager. I still behaved like a lead developer, focusing on agile practices, system design and the details of RESTful hypermedia design.

I waited too long to talk to the APIs end users - mobile client developers, front end developers, testers, product operations, even select third party partners. This should have been the starting point.

It’s extremely common to see internal or ‘technical’ products missing explicit product management. But in lieu of it, that work is done in any case. The question is whether it is and can be done well.

We need to detect when we find ourselves in a situation like this, where we have taken on de facto product management responsibilities.

Ask yourself these questions:

Who are your end users? Even if they are internal people, they are people.
Who has responsibility for representing those users in the team? I someone explicitly assigned to this or does it fall to a team lead?
Are users’ needs being constantly researched, tested and validated?
Does the product have a clear reason for existing? Is that reason well understood by the whole team?
Who is responsible for setting the overall direction of the product?
Does the company even talk about this thing as a ‘product’? Or is it a ‘tool’, a ‘framework’, a ‘platform’, a ‘system’?

Some examples of products that we often forget are products:

Design systems (this is probably the most common product a front end developer will end up leading)
Product admin and operational systems
Financial systems
Content management systems
Developer tools
Code libraries
Build systems
Continuous integration and deployment pipelines

In most growing product companies I’ve come across, some or all of these receive scant product management attention. That’s problematic.

If you find yourself as a de facto product manager, get yourself a rapid product management education. You can start straight away by identifying and interviewing one end user today.

All the best,

– Jim

What do you do, exactly?

Fri, 29 Mar 2019 00:00:00 +0000

Jabe Bloom tweets:

In org design most everyone only has a role “in”… so few “between”

Boundary Spanning roles (often left to management) are critical… and far too often “replaced” by brittle policy…

At first I assumed that this was the start of a long thread. Alas, any further conclusions are left to the imagination of the reader (and to be fair, the repliers, from which the title of this post is shamelessly stolen).

I’m no expert in organisation design, but this did get me thinking about cross-functional product teams.

My wife and I have a long-running joke that she doesn’t really know what I do for a job, like Chandler from Friends. To be fair, it’s changed a lot over the years.

Ten years ago, if I was asked “What do you do, exactly?”, my answer could quite simply be “I am a web developer for [org] working on [project].”

Even within a larger organisation with many products, projects and teams, our working identity is tied very tightly with the team that we are in. “I’m a front-end developer working on the login and registration team.”

I worked in one large company where there were very strong boundaries between project teams. Collaboration rarely occurred as internal team autonomy was highly valued. We had complete control over almost everything we did. But this also meant that we missed opportunities to learn from other teams, to make use of common tooling or platform capabilities, and to foster an identity outside the scope of the team.

These days, the popularity of matrix management and Spotify-style approaches to org design in tech mean that cross-team collaboration is also encouraged. It’s now possible to maintain separate, overlapping identities within a single organisation: Lead Developer on Growth Squad, Front End Chapter lead, Knitting Club social secretary, Kubernetes Interest Group co-organiser. And all of these can be independent of someone’s seniority, salary and position in the org chart.

Social status is a complex thing. And it has increasingly little to do with job titles, remuneration or LinkedIn connection counts.

So when someone asks you “What do you do, exactly?” how do you answer?. Hit reply and let me know.

All the best,

– Jim

Whither the front-end technical co-founder?

Fri, 22 Mar 2019 00:00:00 +0000

One startup trend I’ve noticed over the last few years, purely through anecdotal evidence, is the rise of the front-end CTO - a technical co-founder who has a skill set focused more towards the top of the stack.

Back when I first worked for a web startup in 1999, tech co-founders focused most of their time on the back-end. It was self-evident that you needed someone with good skills in this area to lead technical aspects of software development, because most of the product value was realised in server-based business logic. Front-end developers were people you hired to make the forms and tables look better and work well across different browsers.

All this has changed now. Market forces ensure that software-based solutions to common problems are eventually commoditised. Custom-written web software is increasingly being eaten by third-party services, low-code platforms, frameworks and libraries, on the front and back-ends. There are examples of this at every level of the stack from data storage and hosting (serverless anyone?) to developer tooling to authentication services and UI component libraries.

The great impact of all this commoditisation is to lower the bar for entry to the market. If you’re trying to find customers for your generic office productivity SaaS product in 2019, you’ll know what I mean. Competition is fierce.

Where at one time it was far easier to corner a small-ish market with a basic product, users seem now to expect far better quality and are able to exercise these expectations by voting with their feet and switching to another offering.

A great user experience is now seen as ‘table stakes’ for SaaS products. Not long ago, investors used to talk about great UX as a good ‘moat’ for protecting the product against competitive pressure and fast-followers. Anyone entering a busy market with a sub-standard experience is going to find it tough.

This is why SaaS startup advice is now so focused on product management, user research, design and market segmentation. The job of the technical co-founder in this context is less focused on building a stable application platform architecture, and increasingly directed towards supporting rapid product experimentation and validated learning. Early on in a new venture, back-end application logic and data storage approaches only need to be ‘good enough’ to support rapid development of the user-facing parts of the product.

Sure, it’s easy to make a mess of a back-end while focusing energies elsewhere. But my job for many years seemed to be ‘sort out the front-end mess created by technical co-founders’*. It’s about time we turned the tables!

Are you a front-end specialist who harbours ambitions to be a startup co-founder? Hit reply and tell me all about it.

All the best,

– Jim

* - For the benefit of any ex-colleagues or co-founders out there, I want to make it clear that all startups create a mess of code at all levels of the stack. It’s a natural and healthy by-product of any startup.

Pragmatic prioritisation

Fri, 15 Mar 2019 00:00:00 +0000

Last week, we saw how we can use cost of delay estimates to compare value-add features with indirect gains such as paying down tech debt or improving tools. Doing this on something close to a level playing field can be really useful.

But the problem with all this is that it is often extremely hard to get even vaguely accurate estimates of true value.

The value of a feature may not be directly linked to hard numbers like revenue
Most features are guesses of value in the first place. Most features fall well short of our expectations
The true cost of tech debt may go beyond simple developer inefficiency
Tool improvements aren’t guaranteed to pay off the cost of integration and maintenance

And so on.

Unfortunately, while cost of delay estimates can be useful in well-understood domains, they can often lead a team astray.

New product development in particular is not a ‘well-understood domain’. We need to take pragmatic concerns into account. For example:

Fixed deadlines / seasonal dependencies
Goodwill / reputation / PR
Compliance / legal commitments
CEO-driven development (preferably not)
Security incidents / concerns
Availability / downtime prevention
Partnership / service agreement commitments

In theory, all of these examples can be expressed in terms of the cost of delay. For example, delaying a bit of work beyond a fixed deadline will dramatically increase its opportunity cost! Many of these examples have non-linear cost / time relationships.

So while we reduce everything to a cost of delay comparison, the complexity of modelling all proposed changes is just too impractical.

What’s the best alternative approach to prioritisation in these circumstances? I’m yet to find anything better than communication, advocacy and consensus-seeking, all based on good-enough research and discovery.

Have you use anything better for prioritising work? Reply and let me know!

All the best,

– Jim

Is it worth paying down that tech debt?

Fri, 08 Mar 2019 00:00:00 +0000

A couple of weeks back, we took a look at how estimating the cost of delay of each proposed feature or change to a product can be used to assess different kinds of changes on equal terms.

The example I gave was extremely simple. Comparing three small feature additions can be relatively straightforward. Simple assessments of value can be achieved for changes that can be directly linked to measured outcomes. For example, improvements to the user acquisition funnel or swapping out a third party email service for a cheaper equivalent.

But most of the scope of product development (not to mention overall service delivery) is so much broader and more nebulous.

Unfortunately, it’s important but not necessarily urgent changes that often prove to be the hardest to estimate in terms of value. If you’ve ever tried to make a case for removing under-used features, making design improvements, paying down tech debt, rewriting inefficient code or improving performance, you know what I mean.

We’re often met with responses like “I agree we need to do that but it’s not the most important thing right now as we’ve got to keep [big customer or partner] on board by building [thing they want].”

And then when that’s done, we may try again, only to be knocked back again by some other Priority One must-have.

It can be hard to make the case for a longer-term viewpoint. My early efforts pushing for long-term technical change often met with failure because I was trying to appeal to the long-term benefits.

But using cost of delay allows you to compare the relative benefit of short and long-term improvements. And it also sounds so much more immediate.

Let’s take another look at our feature examples from last time, but we now have another option: paying down some tech debt first.

Let’s assume that the tech debt improvement work is not major, but is in the part of the system that we’re planning on adding more features to. The team has estimated that the tech debt work will take 3 weeks to complete, but completing it will make delivering subsequent features approximately 20% quicker.

Let’s see what impact doing this work will have on the overall cost of delay.

Remember:

value is in Guatemalan Quetzals (Q)
CD3 = Cost of delay / duration / 1000

Here’s the cost of delay, ordering features by CD3, which we discovered was the most efficient approach:

Feature	Dev time	Value to business	CD3	Cost
A	2 weeks	Q5,000	2.5	2 * Q5k = Q10k
C	1 week	Q2,000	2	(1 + 2) * Q2k = Q6k
B	6 weeks	Q10,000	1.7	(6 + 1 + 2) * Q10k = Q90k
Total	9 weeks	Q19,000	-	Q106,000

And here’s the same calculation with the tech debt work performed before moving on to features:

Feature	Dev time	Adj dev time	Value to business	CD3	Cost
(TD)	3 wk	3 wk	Q0	0	0
A	2 wk	1.6 wk	Q5,000	2.5	(3 + 1.6) * Q5k = Q23k
C	1 wk	0.8 wk	Q2,000	2	(3 + 1.6 + 0.8) * Q2k = Q10.8k
B	6 wk	4.8 wk	Q10,000	1.7	(3 + 1.6 + 0.8 + 4.8) * Q10k = Q102k
Total	12 wk	10.2 wk	Q19,000	-	Q135,800

Oh dear! Our overall cost of delay is 28% higher if we do the tech debt work first!

In this case, if we could be sure that these are the only three features we are going to add in that part of the product, we probably shouldn’t bother with the tech debt improvements if the only benefit of them is to make development work more efficient.

But if you’re planning a whole programme of work lasting more than 9 weeks, with extensive business value, the picture starts to change. Let’s add a complicated, high-value feature (feature D) to the mix.

First, without doing the tech debt work:

Feature	Dev time	Value to business	CD3	Cost
D	16 weeks	Q48,000	3	16 * Q48k = Q768,000k
A	2 weeks	Q5,000	2.5	(16 + 2) * Q5k = Q90k
C	1 week	Q2,000	2	(16 + 1 + 2) * Q2k = Q38k
B	6 weeks	Q10,000	1.7	(16 + 6 + 1 + 2) * Q10k = Q250k
Total	26 weeks	Q65,000	-	Q1,146,000

Even doing the new feature first (because it has the highest CD3 value), we can see the massive impact it has on overall cost of delay!

And now with the tech debt work up front:

Feature	Dev time	Adj time	Value to business	CD3	Cost
(TD)	3 wk	3 wk	Q0	0	0
D	16 wk	12.8 wk	Q48,000	3	(3 + 12.8) * Q48k = Q758.4k
A	2 wk	1.6 wk	Q5,000	2.5	(3 + 12.8 + 1.6) * Q5k = Q87k
C	1 wk	0.8 wk	Q2,000	2	(3 + 12.8 + 1.6) * Q2k = Q50.6k
B	6 wk	4.8 wk	Q10,000	1.7	(3 + 12.8 + 1.6 + 4.8) * Q10k = Q222k
Total	28 wk	23 wk	Q65,000	-	Q1,118,000

That’s a pretty marginal difference, but it’s now more efficient to do the tech debt work first - just.

Note that the value to the business of the tech debt work is set at zero. That’s just the immediate value of doing the work. If the benefit of completing it is mostly one of development efficiency, it has latent value that converts to real value as more development work is done that benefits from it. In this case, the difference between the two final cost of delay values: Q1,146k - Q1,118k = Q28k.

Looking at this, it should not be hard to see how even a 20% improvement can pay dividends if we’re planning an extensive programme of work on this part of the product. But how quickly it does so is down to the value of the subsequent work to the business and not just how long it takes developers to create features.

This approach is not limited to tech debt. Any other work that might impact the team’s future ability to drive through value can be assessed in the same way. For example: building a component library, making improvements to test and release pipelines or adding a new team member. If those changes don’t go to plan, you can also see how it negatively impacts the cost of delay…

The figures I’ve presented here are hypothetical. In reality, you’re looking for unequivocal evidence one way or the other, because of all the assumptions baked into the estimates of value and time. If your estimates produce a marginal difference like the example above, you should probably make decisions based on more pragmatic concerns.

Next time we’ll look at some examples of these pragmatic concerns and how they can make a mockery of cost of delay estimates like those above.

Are you weighing up the possible benefits of some long-term improvement work? Why not try doing a napkin calculation like the one above to get a feel for the cost of delay? If you do this, I’d love to hear about it.

All the best,

– Jim

Cost of delay and the elusive nature of value

Fri, 22 Feb 2019 00:00:00 +0000

In last week’s message, we looked at why development estimates should not be used for prioritisation - they are a poor proxy for overall cost.

Instead, we need a prioritisation approach that more closely reflects the importance of each piece of work to the business. We should be able to compare each proposed change - whether it aims to add value through new features, to improve existing features or to remove obstacles to value delivery.

That last category of change can be hard to make a case for because they are rarely compared on equal terms. We are focusing on the cost of doing the work, and not on the relief that completing the work will provide to the cost of subsequent work.

In the world of lean, estimating the cost of delay aims to provide a way to make better comparisons.

Let’s create a simple example of three new features for illustration. For each feature, we magically have good estimates for overall development time and for the value that having the feature available to users will add to the business. (Value is in Guatemalan Quetzals, of course).

Feature	Dev time	Value to business
A	2 weeks	Q5,000
B	6 weeks	Q10,000
C	1 week	Q4,000

Assuming these estimates are reasonable, what order should we deliver the features in? Which order of work will deliver value most efficiently? There are a few ways of prioritising:

Work on them all in parallel and wait until they are all complete to release (assuming a team of at least three). This is the same as not prioritising at all.
Value priority (most valuable first)
Duration priority (shortest first)
Both value and duration priority - i.e. the cost of delay divided by duration, divided by 1000, known as CD3.

Here are the same features with their CD3 values:

Feature	Dev time	Value to business	CD3
A	2 weeks	Q5,000	2.5
B	6 weeks	Q10,000	1.7
C	1 week	Q2,000	2
Total	9 weeks	Q17,000	-

Now if we take each priorisation scheme in turn, we can work out the overall cost of delay.

1. Parallel development / big bang release:

It will be 9 weeks until any value is generated, and we lose Q17,000 every week in opportunity cost, meaning a total cost of delay of Q153,000.

2. Value priority

Here we work on each feature in order of value and release as soon as it’s done. The cost of each feature is the total weeks of delay - including queing time and development time - multiplied by the value.

Feature	Dev time	Value to business	Cost
B	6 weeks	Q10,000	6 * Q10k = Q60k
A	2 weeks	Q5,000	(2 + 6) * Q5k = Q40k
C	1 week	Q2,000	(1 + 2 + 6) * Q2k = Q18k
Total	9 weeks	Q19,000	Q118,000

3. Duration priority

Feature	Dev time	Value to business	Cost
C	1 week	Q2,000	1 * Q2k = Q2k
A	2 weeks	Q5,000	(2 + 1) * Q5k = Q15k
B	6 weeks	Q10,000	(6 + 2 + 1) * Q10k = Q90k
Total	9 weeks	Q19,000	Q107,000

4. CD3 priority

Feature	Dev time	Value to business	CD3	Cost
A	2 weeks	Q5,000	2.5	2 * Q5k = Q10k
C	1 week	Q2,000	2	(1 + 2) * Q2k = Q6k
B	6 weeks	Q10,000	1.7	(6 + 1 + 2) * Q10k = Q90k
Total	9 weeks	Q19,000	-	Q106,000

Some conclusions:

A big bang release is much more expensive than any incremental release order
Working on the most valuable item first isn’t necessarily the most efficient approach
In this case, prioritising by the cost of delay is not much better than prioritising by duration.

Results will vary enormously depending on what work you’re comparing.

Of course, in real life, things are not as simple as this example.

In particular, how do we arrive at the estimate of value for each piece of work?

What’s the value of work that keeps a key partner on board?

What’s the value of reducing churn by 0.5%?

What’s the value of rewriting the user authentication service?

What’s the value of introducing a design system?

It’s for this reason that it’s usually better to describe features as ‘bets’ or ‘guesses’. And technical work can be just as hard to value.

But I don’t think this means you shouldn’t try. Having value conversations and being transparent about its complexity is a key part of making appropriate prioritisation decisions that the whole team can get behind.

Value and cost of delay discussions keep the team focused on what’s important for the business and not just motivated to become the most efficient execution unit it can be, measured only by how hard they are shipping.

How might you start thinking more about value and the cost of delay in your work?

All the best,

– Jim

Don't use story points for prioritisation

Fri, 15 Feb 2019 00:00:00 +0000

Anyone who has worked in an agile team is fully aware of some of the problems with story estimation. While estimations can be useful internally, story points and person-hours estimates are often misused to assess team performance or output from the outside.

“Why did you only complete 33 story points this sprint when you completed 52 in the last sprint?” is a valid question for a team retrospective, but no so great if it’s coming as a challenge from an external stakeholder. This is a sure sign that a team is being assessed purely on output rather than outcomes.

But perhaps my biggest gripe is using estimates as a proxy for cost during backlog prioritisation.

At first this seems reasonable. Take this example: you have two features in the backlog - feature A and feature B. Both are worth an equivalent expected value to the business. The team has estimated feature A at 13 story points and feature B at 5 story points. Any team would pick feature B to work on first, right?

OK, here’s a spanner in the works: feature B will put an extra 30% workload on your already over-worked customer support team. But feature A is a behind-the-scenes improvement that requires no extra support effort. Unfortunately it also requires an approximate 5-10% increase in infrastructure costs.

Now which do you choose?

If you’ve put your business person’s top hat on, the correct answer is: not enough information. You’ll need a better understanding of operational costs and impact to get there.

In the real world, a team also has to collectively decide between features and ongoing internal improvements like paying down tech debt. If a team never gets to work on internal improvements, that’s also a sure sign that informal or formal team success is defined by fancy-named but vacuous vanity output metrics like feature throughput.

A story estimate is only a small part of the true cost of a feature. There are really three main factors:

The cost of actually building the feature while in development
The cost of actively keeping the feature in production - e.g. computing resources, bug fixes, customer support, etc.
The opportunity cost of delaying release due to time spent waiting in the product backlog, in idle states during development and while user awareness builds.

A product team typically estimates some approximation of 1) in order to work out how many stories they can deliver for a sprint. But the other two are rarely considered in detail as part of prioritisation. It’s worth thinking through a few examples to understand how much hidden cost is in 2) and 3).

Of course, in order to prioritise effectively, it’s also important to estimate the upside of having the feature in the product. Like any business decision, both the value and cost of an activity should be at least estimated before proceeding. It’s amazing how little this happens in product development, though.

Unfortunately, determining the value upside of work is often seen as the sole purvue of the product manager, while it is the developers’ responsibility to determine the cost (where ‘cost’ is defined as cost of development only).

In fact, combining the two estimates are vital for creating a prioritisation approach that the whole team can get behind and discuss on equal terms.

This is why tech debt ‘stories’ are impossible to prioritise ahead of low-value features. They just aren’t being compared on equal terms.

Next time we’ll look at how cost of delay can be used to highlight the true value of paying down tech debt. Yes, even that long-neglected spaghetti of a CSS code base you’ve been meaning to improve for months or years.

In the meantime, reply and tell me about a feature you have worked on that had some unexpected costs once it was put in the hands of users.

All the best,

– Jim