Sunday, February 27, 2022

Unplanned work is killing us – really?

One of the things I often hear teams complain about is the amount of unplanned work they have to handle.

Drowning in irrefutable small requests

This unplanned work also frequently seems to be “irrefutable.” But is it? What does it mean to take up an unlimited amount of irrefutable work that has to be done right away?

Starting a new task immediately when it arrives means that you either have been idle when it arrived or –just as plausible– you had to put the stuff you were working on to the side. As long as you only have one item of irrefutable work at a time that might work. However the problem begins as soon as the next piece of unplanned work arrives before you were able to complete the current one.

In this situation you’re most probably not idle (since you’re working on the previous irrefutable piece of work) and you can’t easily put away your current work (because, well, it is also irrefutable).

This dynamic usually leads to a cascade of interrupted work that has been labeled as “irrefutable” and that still gets tossed in the “waiting bin” at the back end.

Most of the time, deciding for stuff to hunker in some “waiting“ state late in the process makes the “client” unhappy – the very person who insisted on the the irrefutability of the work.

This problem gets worse because often there isn’t any time to inform the original client that their work has been paused. After all, the new piece of irrefutable work had to be started immediately!

Thus, even though people try to work on the requirements coming at them as fast as they can it seems to be an uphill battle without much chance of ever getting a grip on the work.

But is that really the only way?

Accept reality

Once we face the fact that in these situations things will take longer to be completed than the mere net working time, we can employ other approaches to get on top of the situation.

There is this seemingly little trick that enables us to transform unplanned work into planned work. It’s called Planning. And the cool thing is that it doesn’t have to be big.

Once you know how many irrefutable small request usually land in your lap each day you can re-structure your day to handle them way more effectively.

You can get that number either from your gut feeling, or from some simple kind of low tech metric like tally marks on a sticky-note near your keyboard. Or maybe just start with an arbitrary guess and iterate towards better numbers later.

Planning to plan

So if you come to the conclusion that if all that work came in structured you could do it in 2 hours a day on average, there are two structural elements you could introduce to your daily structure to handle this

  • Firstly block out those two hours from your schedule. You will lose 2 hours per day anyway in which you will not be working on standard work. This is part of the “accept reality” thinking.
  • Set aside a couple of minutes for planning when you will work on these items and for feedback every couple of hours. Assuming you work 8 hours a day, I would take 5 minutes every two hours for “planning” which leaves us with 2 planning events per day.

All you do in these 5 Minutes is a quick check whether the requests actually fall into the category of “small” request.

If they do, schedule them for later today or next day, based on a rough guesstimation of the amount of work you already scheduled for the respective window and the perceived importance of the task. After scheduling the request you might want to let the client know that you scheduled the item and for when.

If they are not of the category “small” you have a different problem at hand – here you might still want to reserve a small amount of time in the 2 hour window to draft a more detailed feedback on why this request has to be discussed on another level. Still, you do this answering as a planned activity.

With just accepting that the two hours you ‘lose’ per day are actually lost for standard work and subtracting 10 more standard-work-minutes from your working day, you can probably convert 90% of your unplanned work into planned work. Without adding to the actual customer lead time of the items that used to ruin your day in the form of unplanned work.

And as almost every situation is unique, you most probably will have to come up with different numbers, but the general principles statet here should be applicable to most situations.

till next time
  Michael Mahlberg

Sunday, February 13, 2022

Is the user story overrated? Some story patterns and formats to learn from

The term “User Story” or simply “Story” as a shorthand for a requirement has become quite widespread these days. But what does it actually mean and how can we benefit best from it?

We all know, what a story is, don’t we?

Let’s try this one on, for size:

“Once upon a time, there was… here goes the story … ever after”

That’s the kind of story that most people in the real world think about, when they hear the term “story.”

In the agile realm stories seem to be a different kind of beast

As I point out below, my personal recommendation is something quite different, but in the realm of Agile, stories seem to be something other than in the rest of the world. Within the realm of Agile, the majority of people seem to believe that the “requirements packaged in the form of a story” is the central element that everything revolves around.

That extends so far, that even the “speed” of development teams is (way too) often measured in something called story-points – even though at least one of the potential inventors of the story-point concept says “I […]may have invented story points, and if I did, I’m sorry now.

And almost everyone in that realm, as well as in its adjacent territories, have –at one time or the other– heard the stipulation that a well-crafted story

  • starts with “As a <role>…”,
  • has an important “…I want <System behavior>…” in the middle
  • and –in the better cases– ends with “…so that <desired business effect>.”

So – why is this incarnation of the concept “story” so prevalent in the realm of Agile? And is it really the best way to handle requirements in contemporary endeavors? To write better stories today, we need to have a look at how stories came to be such an important instrument in the realm of “Agile Software Development”1 in the first place.

How stories came to software development

Back in the day, before the “Manifesto for Agile Software Development” was written, there were several approaches whose champions called their movement “lightweight software development” and who would later come together and write down what unified their approaches under the moniker “Agile Software Development.” These approaches used all kinds of helpful ways to describe what the system should be able to do.

In Scrum they had the PBI (Product Backlog Item), in Crystal the use case was somewhat prominent, other approaches used comparable artifacts. Extreme Programming was the one that used something called a User Story.

This concept of the user story somehow had such an appeal, that many of the other approaches embraced the idea – more or less.

It was more about the telling, than about the story

A key component behind the idea to use “stories” has even made it into the Manifesto for Agile Software Development – To quote the sixth principle from that manifesto

“The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.”

Before the recommendation that requirements should be talked about was written down in that form, it was embodied in ideas like CCC Card – Conversation – Confirmation or the nice quote from the Book XP-Installed from the year 2000 that a card is a promise to have a “series of conversations about the topic.”

Unfortunately, in today’s world the concept of On-site customers often has been reduced to a person who is called Product Owner but doesn’t have any real business authority and spends about two hours with the team every two weeks. Under these circumstances it seems questionable whether this approach to product development is still viable for all cases.

But I am convinced that understanding why it was okay to write only one sentence to represent a complex requirement back in the early days of lightweight methods helps a lot with writing good stories today.

The fact that the way of working that lead to the original user story is hardly feasible in today’s “corporate agile” with all its compromises, has a direct impact here. It implies that we need something more than just the concept of a “User Story” if we want to capture and process requirements in an efficient manner.

Don’t put the story in the center, focus on the value and the work item

What most approaches propose, is some container that represents “value for someone.” In the process framework Scrum this is called Product Backlog Item, in more general approaches –like the Kanban Method– it is often simply called Work Item.

Such a work item –to go with the broader term– can have many structures. A few common attributes of many such item types are:

Of course, one of the attributes needs to be the actual requirement. And that could be represented by a story. But does that have to be a user story? Actually, there are some pretty helpful alternatives out there.

If you use some kind of story, get to know several types of stories well

As it is often the case, the habitat of the original user story provided many things that were no longer present once the concept was mimicked elsewhere. And as time went by, some people re-discovered what a story could mean for them. Some other people –many, actually– got confused by the story concept since they never really saw it in action and only knew about it through very indirect word of mouth.

Stakeholder Story

After the “As a «role» I want…” format for user stories had been around for quite a while, Liz Keogh pointed out that many of the so called user stories out there are not actual user stories but instead Stakeholder Stories.

  • Format of the Stakeholder Story
    • Liz Keogh described her ideas and observations in the 2010 Article “They’re not User Stories.”

    • The generic form of this kind of story –the way I use it these days– is

      • In order to «the required business effect»

      • «some stakeholder or stakeholder persona»

      • «wants,need,requires,…» «some kind of system behavior or future state»

  • Context for the Stakeholder Story
    • This is an extremely useful perspective if you have to describe requirements that are not actually wanted by the end user of the system, or that don’t actually have a direct user interaction.
    • Most of the requirements I encounter in enterprise contexts are more stakeholder-driven than user driven. (Legal requirement for example. Something like “To avoid being sued for GDPR violations our CISO requires that we have some GDPR-compliant deletion mechanisms that could be executed at least manually if ever a user actually should file a complaint that conforms to article 17 of the GDPR.”)
  • Caveats for the Stakeholder Story
    • The stakeholder should be as tangible and concrete as possible. Unlike with the model of personas in user stories for stakeholders in user stories, it is extremely helpful to name a real person for stakeholders in stakeholder-stories.
  • What to avoid for the Stakeholder Story
    • The most common problem I see with stakeholder stories these days is that the required business effect gets confused mixed up with the system behavior or future state.

User Story

It was probably Mike Cohn who popularized the now so common form of user stories in his 2004 and 2005 books “User Stories Applied” and “Agile Estimation and Planning” but to my knowledge Rachel Davies came up with it around 2002 at Connextra (actually that’s also what Mike Cohn’s post about the three part user story tells us)

  • Format of the User Story
    • The now prevalent way to capture user stories is the well known

    • “As a «role or persona» I want «system behavior» so that «desired business outcome».”

    • This is described (amongst other sources) in the often quoted Article Why the Three-Part User Story Template Works So Well by Mike Cohn.

  • Context for the User Story in this sense
    • Helpful if you really have a product (sometimes a project and seldomly a service) that has actual interactions with actual users
  • Caveats for the User Story in this sense
    • It should describe an interaction between a user and a system that will be possible after the requirements has been implemented.
  • What to avoid for the User Story
    • A story like “As a team member, I want another team member to implement the database logic for the WhatNotField so that it will be available” is using the format alright, but misses almost all point of using User Stories.

Job Story

To my knowledge the whole “Jobs to be Done” way of approaching product challenges became popularized through Alex Osterwalder’s work with Strategyzer around the value proposition canvas. [Please let me know, if you know the whole back-story, I’d be really interested in learning about that] Soon after that the JTBD idea proved so powerful that it spawned it’s own community.

Thanks to my esteemed colleague Matthias I learned about the job story format and the whole idea of using job stories to work on product ideas

  • Format of the Job Story
    • The article Replacing The User Story With The Job Story describe the idea of the Job Story as separating situation, motivation and expected outcome by using the format
    • When ________, (the situation part)

    • I want to ________ (the motivation part)

    • so I can ________ (the expected outcome part)

  • Context for the Job Story
    • Good for very young stories, when you still try to figure out what you’re really talking about.
  • Caveats for the Job Story
    • Unlike Stakeholder Stories and User Stories, Job Stories don’t (yet) provide an easy way to fill out the ________ part, so you really need to dive into the ideas outlined in the above mentioned articles and there can be a lot of discussion about the “right” way to write such a story.
  • What to avoid for the Job Story
    • Don’t treat it like a piece of functionality that just needs to be executed. Job Stories make for good candidates or the narrative flow of Story Maps. There’s also an 2-page summary explanation of Story Maps if you want to know more about that concept.

Of course this only covers some aspects of the usage of stories in todays post-agile society, and I would strongly encourage anyone to look (deeply) into the stuff about INVEST and SMART and at User Story Mapping, to get event more background with regard to working effectively with stories to represent aspects of requirements, but I hope this article gives you some ideas on when and how to use some other kinds of stories to represent requirements that are really hard to fit in the “As a «Role» I want…” format.

till next time
  Michael Mahlberg


  1. (Remember: There is not really an Agile Manifesto)↩︎