First of all, let’s start with one thing: The plural of status is status, spoken with long “uu” but written in the same way. Yes, I googled it a long time ago, it took me 17 seconds, but it enriched my life. I mention this only for those who would otherwise have expected a plural like stati or statuses and are otherwise confused when reading the article.

In Scrum we try hard to keep things simple and concentrate on the essentials, and most of the time we manage pretty well.

And then suddenly and out of nowhere, there are JIRA workflows and Scrum boards with dozens of status and workflow branches. Take a look at this picture.

Unfortunately, it might even seem familiar to some people, but in reality, this is a nightmare.

This is the workflow of a real customer project, no joke. The bigger the project, the more complex the workflow.

But is this necessary?

No. Quite the opposite, in fact. In a long-running project with more than one hundred developers, where we strive for consistency in the way we work and fight for a high degree of effectiveness on a daily basis, workflows like this can cause quite a fuss in Scrum teams.

I often used to ask team members if they could tell me the difference between the status “resolved”, “done” and “closed”. Certainly one could find a plausible explanation, but in reality it is often the case that these status appear in a colorful mix in the backlog and that five people provide just as many different interpretations of these status.

While project organizations tend to invent new roles all day long – and many of these roles might even make sense to them – in Scrum we need just three roles.

Of course, there were lots of status in two-year or multi-year waterfall projects, because they only go through one long iteration. The flood of status in Scrum is reminiscent of these old waterfall cultures.

Today I won’t try to create so much suspense – I’ll just make my recommendation right away.

Three Status in the Scrum board are sufficient

Yeah, you read that correctly. Three.

With “Open”, “In Progress” and “Done” you can manage almost every project in practically any organization and, if necessary, even pass all kinds of quality gates.

Add the flag “On Hold” for the sake of better clarity, and that’ s it. Why?

“Testing” is not a Status

Let’s take the most popular and probably most unnecessary status “In Testing” as an example for many other status apart from the three mentioned above.

Whenever I see the status “In Testing” in a Scrum board, I just can’t help wondering why we don’t have the status “In Thinking”, “In Frontend Development”, “In CSS Refactoring”, or “On Lunch Break”.

This implies that testing isn’t part of the implementation. This is in fact the answer I get most of the time.

“The implementation is finished and now all you have to do is test it” (with emphasis on “only”).

Oops. Strangely enough, hardly anyone has thought of introducing the status “In Documentation” yet. I see, there is no documentation in Scrum anymore (forgive my sarcasm).

Testing is not a status, but an activity.

It is an activity that is planned, assigned, executed, tracked and completed in the same way as any other implementation step, for which subtasks are created as a matter of course.

The same is true for pull requests, tech investments, documentation, etc., which are also often listed as a status and not as subtasks.

The Difference between a Status and a Subtask

Why is it not irrelevant if a Story’s status or subtask is within the Story? There are several reasons for this.

I can estimate, plan and track a subtask.

I can create statistics about how much time is spent on average on tasks, such as net value added, and how much time is spent on everything else.

A status cannot do that.

For example, if it makes sense to introduce test automation, I can more easily evaluate if I add up all subtasks that deal with testing and analyse the tracked time.

This is also the case with subtasks that, i. e., involve all continuous integration (CI) efforts to see if we have the right CI strategy.

One of my projects revealed the rather surprising fact that we have 28% for pure implementation, i.e. net added value, but just over 30% for CI and a further 20% for manual testing (apparently there was no documentation at this stage).

It quickly became clear that something had to change. But above all, it was also clear exactly what had to change first and why.

Setting a status for a Story won’t tell me how long the Story will stay in this status.

But that’s exactly what is of interest to me. I want to know when a Story is likely to be finished and what else needs to be done. With a status, I don’t even know exactly what will follow, particularly if there are half a dozen or more status that can be, but sometimes don’t have to be passed.

And the Clarity?

Frequently it is then mentioned that the status in the Sprint backlog lead to more clarity and that I can see at a glance what is going on with the Stories and the Sprint.

But that’ s a joke! Let’s be honest: If you do good Scrum and have as small a team as possible – let’s say 6 people – and as short a Sprint as possible – ideally a week or two. Then you usually have between 5 and 10 Stories in the Sprint, which should be done from top to bottom. In addition, there are a few bugs from the last Sprint, also between 5 and 15, depending on size and circumstances.

When I’m a Product Owner and want to see how my team works and I have only three status for the swimlanes of my Sprint Backlog on the Scrum Board, I need a maximum of 30 to 90 seconds to see where we stand. And of course I do that daily or even two times a day.

Managing the flood of status – if it is even maintained properly by the team – definitely takes more time. Because I – and this is also reality – can’t trust that the status are always maintained correctly, the whole thing doesn’t do much good.

Status vs. Subtasks

And the disadvantages of status versus subtasks do not stop there.

Teams are required to complete Stories as quickly as possible.

This is less about efficiency than about effectiveness.

We prefer having several developers complete a Story together than having five developers working on five Stories in parallel.

After all, it would be fatal if they all didn’t finish their respective Story and we are left with nothing at the end of a Sprint.

So ideally, Stories are not only implemented vertically, but also by several cross-functional developers. It can happen that the iOS implementation can be tested while the Android guys and girls are still at work.

So what is the status of the Story?

Setting a status always implies a full sequential execution of a Story – as we know from waterfall processes. Then it’s not surprising that some people translate Scrum to micro waterfall every now and then, which is fundamentally wrong and encourages this kind of misinterpretation.

Conclusion

All that is needed for a complete, vertical and end-2-end implementation of a Story are activities; they should also be treated as subtasks.

Testing, CI, review are activities that are equivalent to implementation tasks.

Subtasks offer the possibility of planning, estimating, assigning, annotating, describing, etc. Status cannot do that.

A Story is “in progress” until everything is done.

With that, all is said. In the course of a (hopefully) short Sprint, we want to know if this Story is already being worked on and if there is a problem (“on hold”) or not.

More information can then be found in the implementation plan, represented by the subtasks.

And let’s never forget that a Scrum Board is supposed to organize the work of a team that is as small as possible for the duration of a Sprint that is as short as possible.

Any such Sprint is definitely too short for half a dozen status.