This is not an Epic

This is a rant...

In a “recent” post Mike Cohn outlines some of the misunderstandings around the the terms «epic», «user story» and «theme».

This article is actually only “kind of” brand new - it is from 2011.

But thanks to the prevalence of Tools and Process over Individuals and Interactions that has been brought to us by tools like Jira for more than ten years now, it seems to me that it is a good idea to look at a few key points again.

For example Mike says:

There's no magic threshold at which we call a particular story an epic. It just means "big user story."

So, sorry folks: an epic does not group a bunch of requirements that do not deliver value on their own together. According to Mike’s old post an epic simply is a story that “[one] didn't get the chance to break […] down into stories that are […] small enough […].”

That’s why it is such a good idea (at least IMHO) to do whatever you like with that “Epic” thingy in Jira – use it to mark other stories, use it as a theme (see Mike’s post for a short explanation of that) use it to signal states if you don’t have a Jira admin in your team etc.

But whatever you choose to do, don’t do functional decomposition by making your epic an enumeration of sub-functions that only deliver value if they are all implemented together.

...end of rant.

till next time
  Michael Mahlberg

What happens left of the Scrum-board?

In the early days of Agile, Agile was very much about customer collaboration and concepts like the on-site customer were at the core of Agile. Nowadays, most on-site customers (actually a term from eXtreme Programming) are some derivative of Scrum’s Product Owners and most instances I have seen are far from the role Ken Schwaber and Mike Beedle described in their seminal work on Scrum in 2002.

Things have changed over the years, and nowadays a product owner (PO) in many places, especially at enterprise scale, is someone who devotes ‘a couple of hours’ each week to support ‘some team’. And even though this is definitely an anti-pattern from my point of view, it still is a reality we have to deal with.

The Agile Manifesto states quite clearly that “Business people and developers must work together daily throughout the project.” (4th principle) and one the biggest benefits of agile approaches in my experience is that they enable projects to start developing (and delivering!) before “all” the requirements are discovered. A huge part of this approach has to do with the fact that the whole team works on requirement discovery and the honing of the product vision.

But those teams are rare.

And while process-frameworks like Scrum – and the secondary literature around it – provide a lot of helpful guidance on how to deliver the solution there is very little said about the process of requirements discovery.

So I would like to challenge you to a little experiment.

• Have a board “left of the board”
  • Instead of just having a backlog and backlog refinement meetings where requirements magically appear try to build a board for this part of your process as well!
    
  • Have just a few columns like “idea”, “described”, “accepted”, and “ready for planning” – whatever fits the real way of work at your place.
    
  • And here is another idea: Unlike on the Scrum board, perhaps here it is not necessary for all items to reach the stage - perhaps it is good if some ‘die’ on their way to the iteration planning.
  • And then observe... What happens on this board?
    • Do items ‘starve’ in some states?
    • Are there items with different speeds?
    • how many items ’make it’ to the next stage?

Who knows - you might learn a thing or two...

till next time
  Michael Mahlberg

P.S.: Inspired by Discovery Kanban of course... ;-)

Nowadays it’s Backlog Management

Back when Agile started out, the focus of many people was on getting things done. Getting things done the right way: with test driven development, continuous integration, merciless refactoring etc., and getting the right things done (with things like the planning game, the system metaphor, user stories and more).

And actually, software development became a lot better in a number of instances. Back then it was mostly eXtreme Programming for me, later things moved towards Scrum – at least in Germany, but also in a lot of other places. Still, the focus was on getting things done. Just by looking at the onmipresent "Scrum in «n» Minutes" presentations or even at David Harveys’s old but still excellent discussion of what is missing in those pictures it is easily discernible that most of the effort is put into the part where things get done.

Apart from the slightly disturbing fact that all those "agile processes" are in stark contrast with the first value pair of the agile manifesto ("Individuals and interactions over processes and tools") there is something else that is slightly underrepresented nowadays. Those pictures always start with an existing (product) backlog. Where does it come from? Of course the ScrumGuide includes the practice of backlog refinement (or grooming prior to 2011), but there is very little guidance on how to actually come up with – and refine – the requirements in the first place.

Even though there are many great tools available – Story Mapping, Impact Mapping, Buy a Feature, the Kano Model, to name just a few – they usually don‘t get too much air-time when agile practices are discussed. So let’s change that. Let’s go back to the old ideas – from eXtreme Programming times – of including the customer in the work, or let’s move forward to the Kanban way of managing work and model the whole value stream of the knowledge work and find appropriate tools for each section. Especially for those sections that lie “left of the backlog”

till next time
  Michael Mahlberg

What is a “must have”?

Language is important – almost always.

One of my pet peeves is the word “must.“

As in “We must have the feature «x»”, or in “We must do it in this manner.“

From my understanding these are incomplete statements. The missing part is about what happens if we don't.

Complete statements would include the consequences. And thus allow the discussion of the topic. When "We must have the feature «x» to avoid paying a £5 fine” we could easily decide that it is not worth the effort. Whereas if “We must do it in this manner to avoid paying a € 5.000.000 fine” the decision is likely to be different.

So, IMHO a “must” must have explicitly stated consequences in order to make it a helpful addition to a conversation.

till next time
  Michael Mahlberg

The difference between bugs and requirements – and how to handle them

What's seems evidently different for some people might appear identical to others. Let’s see how different bugs and requirements really are.

There are different ways to look at this question...

By definition

If you look up the definitions of at the terms “bug” and “requirement” they may seem only vaguely similar, clearly distinct

Bug: “A [...] bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.” Software Bug, Wikipedia

 

Requirement: “1) A […] capability needed […] to […] achieve an objective.
2) A condition […] that must be met […] by a solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3) [omitted]” IEEE, via Wikipedia

By point in time

But if you look at them by the point in time when they become manifest, they become a bit more similar.

A thing (like maybe some ‘feature’) that is not ‘available’ now, is just a requirement: “Cars should have visible (blinking) indicators that show where they want go” was a requirement before indicators were invented.

A thing that has been there once, but subsequently has disappeared, sometimes is a bug "That car's indicator should blink" is a bug report for a car on the road today.

So in some cases whether you look at a bug or a requirement just depends on the point in time you're at.

By reaction

When one looks at bugs or requirements with regard to the possible ways to handle them it somehow pays off to be sure who is looking. For now lets focus on the customer (product owner, product manager etc. – the person who pays for the things that the development team spends time on).

I don't see any reason at all to react differently – except with regard to further context.

Given that a so-called ‘bug’ surfaces in an already published piece of software that is used regularly the fixing of a bug has to have some budget allocated. And obviously it needs to be prioritized. From a business point of view this means that fixing a bug just is fulfilling ’a condition that must be met to satisfy the formally documented desired behavior’ for this bug ... sounds familiar?

If, on the other hand, the bug surfaces during the acceptance phase of a feature (or ‘system capability’) the situation is straightforward. Since the error wasn't present in the previous version of the software the new feature can't be accepted. The instruments of the respective process should be used to remedy the situation. That could be blocking the work-item, swarming, stop the line etc. – each way the error has to be fixed before the new feature can be accepted. Not a bug – just a requirement that has not yet been met.

By common (agile) sense

Now if we believe in test driven development (tdd) we start implementing each thing by writing some tests that tell us when we are done. If we follow behavior driven development (bdd) we might be able to map requirements directly to one or more bdd-specifications. Which we write first, before we implement the capability.

The first thing we do with a bug is to check whether we can reproduce it. Some people then write a test that demonstrates the bug. (according to the rule, that you just don‘t write any code that isn't required by some broken test)

So bugs and requirements are both firstly described by a test that is ‘red’ (or breaking) and then implemented – not much of a difference here.

By work item type

Now this a thing that even in my opinion justifies to differentiate between a bug and a requirement – or isn’t it?

I think in some cases bugs (from a system that is already in use) are different from other requirements in the ratio between size and value. So while most system capabilities that can be described by user stories are comparatively expensive while bugs sometimes are cheap to (e.g. with little effort) fix and yield a high value by making the user experience much more enjoyable (for example if they don’t have to confirm erroneous error messages any longer).

There is no bug

In the end a bug just is special kind of requirement. And when and whether to fix it should be a business decision just like any other prioritization of requirements. For a web-based shop-system that has the bug “’stay logged in’ doesn't work” and a feature request “Add the capability to use the most commonly requested credit card” the decision what to do next might very well favor the feature over the bug. From a business perspective it might be acceptable for a while if users have to re-enter their credentials every time, even though they activated the “stay logged in” box while not having the capability to pay by credit card can be a real problem for the business.
Some bugs are quite easy to live with, while it’s really a nuisance to live with some unmet requirements.

So – how do you handle your so-called bugs?

till next time
  Michael Mahlberg

Requirements - a different IPO than that at the stock exchange

I really do love Mike Cohn's format for user stories, but while formulating requirements in the form

"As a <type of user> I want <desired system interaction> so that <desired outcome>"

is very helpful for capturing requirements, it is in no way sufficient.
The point is not only that user stories really have to be written from a user's point of view.
Writing genuinely from a users perspective means that there should not be any story

"As an internet-user I want the system to perform garbage collection so that the server doesn't have to have too much memory."

because, quite frankly, most internet users don't care about garbage collection or the server's memory - they care about response times, user experience and (hopefully) the service that is provided.

But there is more to good requirements than just writing a story from a users point of view – one of the intriguing stories from Tom DeMarco's The Deadline is the one where a bunch of people read a 18-binder specification for a system and none of them dared to tell the project manager that they did not really understand what it was all about. Those binders where full of technical detail and elaborate formulas but lacked a couple of important things nobody noticed at first.
Until somebody asked "Where does the data come from?" and another one chimed in "Where do the outputs go to?" After that magical moment the spell was lifted and all kinds of missing information were was surfaced. In the end the specification was reworked and the project could go ahead.
Which brings us to the basic point of every operation in a system - there has to be an Input, some kind of Processing and an Output. In the olden days there was a name for that concept, it was called the IPO model and used to be applied to hardware as well as to software.
And even though we (hopefully) don't write our programs anymore as the sequence 'input division', 'processing division' and 'output division' the basic structure for requirements is still quite valid. If the input or the source of the input is unclear it is hard to decide how it should be handled. If the postprocessing is unclear – the output – it is hard to decide what to do with the results from the processing.

So for every requirement – if it is formulated as a user story or in any other way – before the implementation starts it should be clear what that user-story's IPO is.

Till next time
  Michael Mahlberg

From the customers perspective...

... a story starts and ends with the customer experience. There are no technical stories.

The technical temptation

From a technical point of view two stories A and B that share some basic functionality might look like an opportunity to extract the technical commonalities in a story C. What tends to happen is that you wind up with three stories A, B, C that can be easily "estimated" and have an obvious order of implementation - you start with implementing the technical commonality C and then, once that is stable you can do A and B on a tried and trusted foundation.
Nice, isn't it?
No - it is not!
Now you would have three stories and none of them conforms to the I (independent) of the INVEST concept for good stories. And what's worse: you end up with a story that is not testable by the user - story C. To add insult to injury, it is even your first story, further delaying the deployment of code that is useful to the end-users.

A solution?

For me the solution to this scenario is to really plan, estimate and analyze in four dimensions. Take the time into account. If you implement A first then A is much bigger than B because once it is finished B gets all the development effort from A for free – or at least the part that turns out to really be usable for both A and B. So B is actually bigger on the inside - unless you travel on a different timeline where B gets developed first. In that case A would be the story that gets the benefits.
In either case, the important message is:

Don't burden the customer with technical stories to get better story-sizing, just look at every story in the context of the moment when it gets implemented.

Value gets delivered only when new capabilities are available to end-users.

Untill next time
  Michael Mahlberg

The Spice Girls on requirements engineering and root cause analysis

Just the other week I came across an interesting thread on the "kanbandev" mailing-list. It was all about "have you asked the Spice Girls question?" which seems somewhat odd, if you consider that this mailing-list is about managing Software development projects...
turns out it is only about the second verse of "wannabe" : "So, tell me what you want, what you really, really want" [you can (and should) ignore the rest of the song for the purpose of this post].
That one sentence actually captures remarkably well what differentiates a shallow requirements or root cause analysis from a thorough one: Asking beyond the obvious to find out the need that fuels the obvious.
according to Jabe Bloom Steven Bungay formulated the question a bit more formally:

[...] This should be encapsulated succinctly in the form... We should do What in order that Why.
For example... We should implement Continuous Delivery in order to minimize Lead time.

But "Tell me [...] what you really, really want" seems to stick a lot better than just "why".
So thanks, Jabe Bloom, for raining this!