Over the last month or so, I’ve been considering whether the workflow dictated by my team’s Scrum board is indeed a mini-waterfall within the Scrum framework.
In this article we look at how you can simplify your workflow and unleash the power of sub-tasks to supercharge your team performance.
Here’s what my teams Scrum board currently looks like:
Does it look familiar to you?
This sort of workflow is fairly typical for a company that is doing agile, but not necessarily being agile. In this article, we’ll look at why.
Let us start with the core question:
Can we improve on this? I think we can.
Review of the Current Scrum Board
At the start of each Sprint (in Sprint Planning), the team decides which Product Backlog items are required in order to meet the Sprint Goal.
These stories are put into the Sprint Backlog, represented as the BACKLOG column on our sprint board:
The Sprint then starts. This all looks fairly innocent so far.
The developers start working on the first story to be tackled, this story is moved to IN PROGRESS, now everyone who looks at this board knows that someone has started on the work.
It would be fairly typical at this stage for the developers to start writing sub-tasks (if this was not already done in Sprint Planning).
Coding would then begin — typically by one developer, but sometimes multiple developers working on a single story if possible.
When the coding was complete, the story would then be moved to FEATURE REVIEW.
At this stage of the process, up to 3 things happen:
- A code review with other developers— to make sure the change is up to our coding standards etc…
- If required, the developer with design expertise would perform a design review.
- The Product Owner would perform a product review; taking a quick look to make sure the conditions of satisfaction of the user story were met (before we incur the larger expense of testing).
These 3 checks can be done independently and possibly in parallel to each other.
Assuming all 3 of those checks pass, the story would move on to READY FOR QA; a queuing status for when no-one is immediately available to test a user story.
When someone does become available, usually a developer with testing expertise, the story would move into QA IN PROGRESS, where it would be tested to ensure it’s ready to release to our users.
Assuming all of these QA checks pass, the final two stages of the process are tackled.
First of all we have another queuing state, WAITING FOR STAGING.
Staging is our final check on our as-close-as-it-can-be-to-production environment. There can sometimes be a queue for this single environment — so we have a queueing status called WAITING FOR STAGING.
When the environment is clear, the story then progresses to STAGING — our final pre-production checks.
Assuming all the final checks pass — the software is deployed to our production environments. The story is marked as DONE and our users can enjoy the benefits of the work (assuming the new feature is enabled for use).
In reality, we find that multiple stories all get started at once, so we have something more like this a few days into the sprint:
Our Daily Scrum meeting involves discussions about each story, moving from the right column (Story 1) to the left columns (Story 3, 4, 2, and finally Story 5).
This all sounds pretty simple and transparent. But, there is something lurking beneath the pretty facade, the sub-tasks.
The hidden work going on underneath.
Sub-tasks are the small steps the team take in order to complete each user story.
They are typically no more than 2 days worth of work (often less)
Sub-tasks also have a workflow:
- TO DO
- IN PROGRESS
Sub-tasks are things like:
- Code the user interface
- Write the automation tests
- Code the backend service
- Write the API
But you can’t see them on our board.
So are we really living the Scrum pillar of transparency here? I don’t think we are.
So we decided to improve that.
Doing something about it
Imagine you are a passer-by, maybe a stakeholder for one of these stories. Do you even know what “staging” means? Is that transparent enough for you?
We discussed these problems as a team, and came up with a new experiment, a new way of representing our work, a way which is so simple it hurts.
The 3 column board.
The 3 column board
To do. In Progress. Done.
This is nothing new or revolutionary. The key to agility here is combining it with our use of sub-tasks.
If we just placed our user stories in these columns, and moved them to IN PROGRESS when they were underway, and DONE when they were finished, then we’d have the exact same problem as before.
We are hiding our sub-tasks.
However, if we add the concept of swim lanes to our board, with each user story as a separate swim lane, then we get something a bit more powerful for a team of people working together.
Here’s what a 3 column Scrum board might look like after identifying the initial set of sub-tasks in Sprint Planning:
Now we can see that our 1st user story has 9 sub-tasks, the 2nd has 8 sub-tasks etc…
We have added a new dimension to our board, we can now see that user story 1 is the most important story, as its swim lane is at the top of the board and that User story 5 is the least important story to complete this sprint.
The team can now focus their conversations in the Daily Scrum around how to finish the most important story. Not which story is furthest along in the process.
If sub-tasks are not dependent on any other sub-task within a story, other team members can now see an opportunity to work in parallel with each other. Leading to us finishing the most important story sooner.
Here’s an example on day 2 of our Sprint:
We can see that:
- For User Story 1, the developer with design expertise has quickly mocked up the UI, and another developer has started to make the code changes. The developer with testing expertise has also started to write the AT tests. We’re working in parallel here!
- For User Story 2, someone has also managed to start writing the AT tests before we’ve started to code the changes required. We’re overlapping tasks now.
We’ve got much improved transparency here, we have shifted the focus from an individual finishing their work on a story, then moving it to the next step in the process, and on to team ownership of finishing all items in a Sprint as quickly as possible.
With a simple visualisation of what’s going on at a sub-task level, we’ve unlocked a potential performance boost for the team.
We’ve uncovered the idea of overlapping work. We’ve unlocked parallelisation with the simple act of making the same work, more visible, more transparent.
We are being agile.
Changes to our Daily Scrum
In order to facilitate the use of sub-tasks, we’ve also changed the way we run our Daily Scrum.
As I mentioned earlier, previously we’d start from the story furthest in the process (on the right hand side of the board) — and discuss what we need to do to get it done. Discussions would then move on to the next story furthest in the process (not necessarily the most important story to tackle next).
This had the effect of having small stories that can move quickly across the board, finish first, regardless of their relative priority to other stories.
Now, the team starts with the most important story, and asks “What do we need to do to get that story to DONE” — the answer is in the sub-tasks.
Passers by can much more easily understand our board — it has three simple states:
To Do. In Progress. Done.
Anyone can understand that.
By moving some of your statuses to sub-tasks, you can unlock hidden performance in your team.
You boost transparency, and make parallelisation easier to achieve. This will lead to a more team-focussed approach to software delivery and ultimately an improvement in overall team performance.
Your stories will get to DONE quicker. Your software will go live quicker.
Getting to market quicker, will allow you to learn what your customers want sooner, and will boost the chances of your product being a success.
Welcome to agile!