Agile Project Management
Agile vs. classic project management
Agile – versus classic project management or more planning, less status Content of this article Time and again, I come across organisations that are in
Menu
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…
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.
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.
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.
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?
Only these statuses are required on the Scrum Board: To do, In Progress, On hold, Done.
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.
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.
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.
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.
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.
Agile – versus classic project management or more planning, less status Content of this article Time and again, I come across organisations that are in
Scrum vs. Waterfall – For all Scrum fans, let’s get the bad news out of the way: Scrum is just a compromise. The good news is that this is the only piece of bad news.
How to get your team to give a commitment and to complete a sprint and wich roles Scrum Master, Daily Standup and Plannings play.
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
