Posted on by | Posted in synyx Blog | Tagged , ,

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.



One Response to Let’s add some value!

  1. Sebastian says:

    From my experience it’s usually a pretty difficult task to help the product owner understanding the value of small parts of an Epic. In that case it really helps to introduce him to the concept of the minimum viable product (MVP) to understand, that even with smaller iterations of his epic business value can and will be generated.

    That’s a pretty common problem I experienced in almost every project. And if it’s not being faced exactly the thing you described will happen: a story runs for weeks and weeks and you’re having trouble completing it besides your daily work and other stories (WIP limits anyone? they are a good tool in basically every agile process).

    For the PO it helps to understand what his epic is about. For example take a dealer search on the website of a company. The epic for the PO might be a dealer search with a map and stuff. But basically you can already deliver the search itself, already generating business value. Then you can add further functionalities like filters, the map view and so on. And for example also the backend will be extended with every story. It’s not the “it can handle ALL the search eventualities from the beginning” thing. This even works for registration forms and similar things. At first it might be enough just to ask for a username and a password. Then you can add personal details etc with later stories which might contain more complex validation mechanisms.

    The problem is: “thinking small” is not only difficult for the Product Owner but for the developers as well. For example: why start by implementing the whole frontend separately and build it against mocks while another part of the team in parallel builds the whole backend? Doesn’t that sound a bit contrary to one of the basic cornerstones “integrate early”?

    Why not build small functionalities instead which immediately integrate frontend and backend where FE and BE at the time of the first story can only really do one thing and nothing more? Of course you also need mocks in there, obviously. But everything would be integrated from the beginning and potentially shippable. Potentially shippable does not mean that it has to be shipped. But it means that you have completed a software increment which is fully integrated and does work. Shipping it would not break the system or leave the user with functionality which makes it impossible to him to use the system.

    Ah, one more thing which came into my mind by reading your post again: implementing stuff without actually releasing it, absolutely collides with the princible of reducing waste – actually you’re even generating waste by doing so.

    So in conclusion: yes, it’s difficult to break down a complex topic into smaller work packages. Especially regarding architecture. But I think basically it’s “just” a matter of good software design. Having common software development principles in mind (like separation of concerns) should help avoid having trouble extending your architecture. So the most important thing is though: make sure your architecture can grow. It’s not really up to detailed specifics of the “big goal” which you should have in mind at the beginning but to make sure your software can grow.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.