Introduction
In this post, I will share the experiments we conducted during the last three sprints with our physical Scrum board. The focus was about creating a better understandable visual representation of our sprint progress. Sprints are two weeks increments for us at this moment.
Our Scrum board right now.
The image I will post below displays the board we have been using for almost a year. As we began to take Scrum more seriously we started to notice a lack of transparency with this board.
In this board we already resolved many of the problems we had previously encountered. These improvements are explained in detail in a previous post: Our sprints in real life.
To gain a better understanding of our journey, "Achieving FLOW with Scrum" is also a must-read. It delves into our background and, more importantly, answers the question: Why are we doing this?
These are the lanes and setup we use at this moment. We have split up the last two (Testing and Done) to improve transparency within our current CI/CD setup. Below is a list of things we have already tested and therefore are implemented on this board. On these improvements we will continue to incorporate when experimenting with new versions of our board.
The sprint goal is clearly visible.
We use green colored cards for the items contributing to achieving the sprint goal.
We mark tasks that are in testing to long with a visual exclamation mark.
We use "released" and "not yet released" in our Done lane to keep things that are DOD but not yet deployed visible for the Scrum team.
Our work order is put on the board in the Todo lane from top to bottom. Top items get worked on first unless there appears a good reason not to work in that order :)
Other tasks we committed to for the sprint are marked blue.
Random bugfixes and potential hotfixes uncovered during a sprint are marked red. They are put in the bottom of the board. They may be important but they came up during a sprint and are visible in the bottom of the "TODO" lane therefore.
Subtasks are always defined on this board. They are for the developers to do the work to deliver the full story. They may reside in Jira but the physical board is leading.
We use name cards to show who is working on what.
The reason we started experimenting with different board setups you will find below is that we increasingly started breaking stories down into subtask. However, when our developers completed a subtask. We didn't want to remove it from the board immediately for a whole lof ot different reasons.
Removing a subtask creates less transparency and instilled less talks about done subtasks.
It gives developers that were out of the office (free) insight in tasks done when they come into the office the next day.
The most important topic was the lack of transparency this board still had on subtasks!
It also feels more satisfying to move a completed subtask to a designated area on the board. Slap it there, and move on. This provides a sense of closure. A feeling you wont get when you immediately remove, clean, and wipe out what you just accomplished.
In the first version of our board we didn't account for this. Sometimes subtasks would move with the story. While other times a subtask moved to the "Done" lane. This is wrong! there isn't anything to release or not yet released. It is a completed subtask of a branch probably not even committed yet. This situation created a lot of issues with regards to transparency.
First iteration changes
We started to experiment with splitting up the "Dev" lane with a "Doing" and "Done". This way we could keep the completed subtasks in a designated lane. Although we noticed some initial irritation in starting with this setup. It was essential to try it out though to determine its effectiveness!
First iteration conclusion
After using this setup for two weeks, our final conclusion is that it's helpful to have a designated area for placing "Done" subtasks. However, including this area within the current lanes of the board is not ideal. Completed subtasks should no longer be visible like this, they now appear as if they still need to move further to the right.
Subtasks themselves don't move in Testing for example, as they are part of a story that holds the value. It is the story that progresses into Review, Testing, and Done. Thus, this approach is not recommended in our opinion.
We did agree to remove the cards when the developers as a collective felt it was time to remove them. But this method also doesn't provide transparency either since there is no clear rule in place.
Second iteration changes
Together we came up with another version of the board. This version is again visible in the image below.
We reverted back to the lanes we had in the start of this experiment. Todo, Dev, Review, Testing and Done. We removed the visual representation of Todo and placed the Sprint goal there instead. We all agreed this was a more suitable location for the Sprint Goal.
We also decided never to move any work above the items representing the achievement of our sprint goal. For instance, if we start working on a blue or red item. This item moves to "Dev" while staying on the same horizontal line where it was initially placed. So, from now on, we aim to keep items horizontally aligned as they move through the lanes. The only exception is the Done lane, which is divided into sections for released and unreleased work.
The "Burn Pile" is a name we came up with for all done subtasks. We wanted to avoid having two "Done" lanes. It just feels satisfying to place the subtasks you just finished in this designated area! This approach not only provides a sense of closure but also offers insight into everything completed as subtasks.
Second iteration conclusion
This is the first iteration of our "Burn Pile" version. We have already discussed some other considerations for trying out this version.
We might need to add a reference to the story for transparency reasons. Or group the same subtasks of a story together for example.
We will learn from this experience by simply putting it into practice. It's essential not to overcomplicate things immediately when it might not be necessary. As seen in the screenshot, we have already placed some subtasks in the Burn Pile, and we all agree that it feels good to physically do so.
Conclusion
We have decided that this board version is what we will be moving forward with for now. The first iteration did not work well due to having too many lanes, too much space, two Done lanes, and subtasks remaining too visible for too long after completion.
So moving forward from now on we will be using this version. I will keep updating this post every time we find improvements within our work using this board.
