Being more successful with 3 statuses in your Scrum Board

No, testing is not a status! Which status do you actually need in your Scrum board and why you’ll ONLY be successful with these statuses in your Scrum board…

Being more successful with 3 status in your Scrum Board | scagile blog

Contents of this article

How it usually happens with Scrum statuses

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 statuses and workflow branches. Take a look at this picture.

Diagramm mit viele Scrum Status | scagile blog

This Scrum board has far too many statuses. It’s pure chaos.

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 statuses “resolved”, “done” and “closed”. Certainly one could find a plausible explanation, but in reality, it is often the case that these statuses appear in a colorful mix in the backlog and that five people provide just as many different interpretations of these statuses.

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 statuses 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 Statuses 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?

Nur 3 Backlog Status | scagile blog

Only these statuses are required on the Scrum Board: To do, In Progress, On hold, Done.

"Testing" is not a Status

Let’s take the most popular and probably most unnecessary status “In Testing” as an example for many other statuses 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 statuses “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”).

Of course. Strangely enough, hardly anyone has thought of introducing the status “In Documentation” yet. Oh right, 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.

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 analyze 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 statuses that can be, but sometimes don’t have to be passed.

Prioritizing with the WSJF Method [+ Excel Template]

With the WSJF Method, PI Plannings become a breeze and more effective than ever before. Click here for the free step-by-step guide and WSJF Excel template.

And the clarity?

Frequently it is then mentioned that the statuses 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 statuses 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 statuses – 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 statuses are always maintained correctly, the whole thing doesn’t do much good.

Statuses 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, and review are activities that are equivalent to implementation tasks.

Subtasks offer the possibility of planning, estimating, assigning, annotating, describing, etc. Statuses 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 statuses.

The app for scaled agile teams is here!

Click here, to show articles with the same tag:

Klaus Riedel

As an agile coach, Klaus Riedel, together with his team, supports the digital transformation and the introduction of Scrum and SAFe in large organizations such as Deutsche Bank, Conrad Electronics, Volkswagen, PWC and others.

All his gained practical experiences in more than 15 years of agile transformation have been incorporated into the articles of his blog.

In Scagile Academy he trains young Agile Experts and since 2016 he teaches agile project management at the German Faculty of TU Sofia.

More interesting articles for you: