Let's add some value!

tl;dr

Follow principles #1 and #3 from the agile manifesto!

“Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software. ”

“Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.”

Or in my own words:

In each iteration ask yourself: While working towards a big vision can we solve at least one real problem by the end of this iteration?

Part 1: The problem with technical stories

In Scrum we deliver a potential shippable product increment in each iteration. Following this directive has many advantages for us:

We can…

• detect errors or misunderstandings very early through feedback from stakeholders
• fail fast by discovering critical problems as early as possible
• find out what users really want/need by experimenting with early versions of a feature
• generate value by solving real problems with each new version of the product
• change priorities based on new circumstances

Often customers have visions which result in very large user stories, also known as epics. Since we can not build the requested feature within one iteration we break it down into smaller work packages. The challenge here is to find user stories which solve part of the problem while still making progress towards the envisioned goal.

A partially finished feature has no value but a smaller feature which solves part of a problem has.

It is often easy to come to the conclusion that only the whole feature provides value because after all we can not go live with a half finished feature.

So we start to create tasks to fulfil the epic:

We…

• analyse the problem
• design a possible solution
• evaluate technology
• implement the frontend with backend mockups
• implement the backend while mocking calls to 3rd party services
• integrate the real 3rd party services
• … and the list goes on

And there can be no objection to that! As long was we do not start to call these tasks stories, fill our backlog with them and start to plan whole sprints with them. But in my experience that is exactly what happens when we are confronted with complex problems. Of course we all know that a user story describes a real problem from a stakeholder which is solved once the story is fulfilled and since our defined tasks do not meet this criteria we call them technical stories. Before I talk about the problems of technical stories, I want to look at the advantages that we can still have if we use them. Since we still work in iterations and (hopefully) deliver some sort of running software after each iteration we can still inspect and adapt.

We can still…

• try out early versions of the software in an experimental environment
• get feedback from stakeholders by showing them design sketches, frontend mockups or partially implemented features
• fail fast if we discover that a chosen technology does not work as expected

That sounds good! So where are the problems? The product increment which we deliver after each iteration can not be used in production and therefore does not generate value until the whole (complex) feature is finished. We miss the advantage of a lesser time to market (to use a management buzz word) which means we loose money. We also do not get feedback from real users which is often the most valuable resource to base further development on.

But here I want to focus on a problem which is less obvious: Generating no value early means that the product owner can not change priorities based on new insights (change in the market situatíon, new requirments from stakeholders, new management priorities). Taken to the extreme we could plan each iteration without the product owner being present until his epic is completed. After all he has already told his story and the decision in which order the tasks to fulfil it must be completed, belongs entirely to the team. Of course we would still work closely together and invite him (and stakeholders who are interested) to a review meeting after each iteration, to benefit from the advantages stated above. But as long as that one large feature remains the highest priority and the whole team can work on it (i.e. the work is parallelisable) the product owner has not much to do.

In reality there are often small change requests or bug fixes getting higher priority which results in a delay of the story. This puts the product owner into a difficult situation. While he always has to prioritize between different needs (= stories) of his stakeholders he now has to decide between fast wins and his most important feature which everyone waits for. Real trouble awaits him if the epic that the team currently works on suddenly is not the highest priority anymore or for some reason takes much longer to implement than expected. Of course we can just delay new stories until the current feature is finished but that might be bad for the project and it is certainly not what we hope to achieve with agile development (being able to react to change). The option to stop development on the feature entirely (which a PO should always have) however would mean that all his money spent up until then is lost without any returned value. That would not be the case if we had solved partial problems on the way towards the big goal. Maybe the feature can be shrunk down to minimize the work needed to get at least some value before we abandon it. But if that is possible why did we not define this smaller goal as a partial solution from the start?

More often than not it is not that easy to get reasonably fast to a smaller solution once we started developing with the big solution in mind. Let us assume that with some additional effort design and technology decisions can be adopted to a slightly changed goal, since that will always be expected from an agile development team. The structuring of the work makes the real difference though. For example a big and complex feature naturally requires a longer analysis and design phase. So by starting with the epic as our goal we might still be working on the design tasks or an implementation task which results in a small part of the final feature, when the product owner announces the change of priorities. Had we started with a smaller goal we might already have implemented something which we can either just finish (to generate immediate value) or adapt to better match the new goal of the PO. When changing priorities we must also be careful not to rush the development because we know that we ideally should already be working on a different story. The quality of the software must always be maintained because otherwise we build up technical debt which must eventually be repaid.

There are some objections that I have come across while talking with developers and product owners about why we do not break down epics into real user stories to avoid these problems. But as this post is already a bit to long I decided to make a series about this topic. This way I can discuss the objections as well as possible answers more detailed in the upcoming parts. Until then I leave you with my conclusion up until now:

Finding ways to generate real value early may be hard but it is worth the effort.