Below, you will find an example of our current visual whiteboard we use. (what's a usable term?). I know that there are still a lot of issues to address to improve our board even further. We already accepted a long time ago that reaching perfection instantly is not possible. Try, Inspect and Adapt..
Mastering neater writing on a whiteboard is a skill everyone wants to own but requires a lot of time and effort. Not everyone is willing or able to commit to this ;)
Introduction
I use the words story below to break up something with subtasks. This is mostly a story for us, which also tells us we are open for discussing the how and the what.
A task is something that just needs to be done or is a specific request to run some query to get an export for example. not a lot of creativity in that :). A task is more defined in the what/how mostly. This is the main difference for us between the two.
Bugs and hotfixes are almost the same for us. except a hotfix gets fixed and deployed immediately. And a bug just moves as normal through the system. We both mark them red on the board so that is still something to work on for us also to create a visual difference.
Subtasks are tasks that get broken up from a story and needs to get done to move the story on. To keep it simple you can say we use the term story for tasks that can get broken up. I dont care about subtasks on the board from the DoD perspective. The value to me is in the whole story we committed to. Subtasks are removed after being done at this moment.
We are reviewing other versions to keep subtasks on the board for X time. I will write another post about these findings when we can analyze them.
Working: TODO & IN DEV
All subtasks under a story move in the TODO lane only when work on that specific story begins. This visually indicates a commitment to finish it. Once all subtasks are complete, the story moves between the lanes. This is because the value of the story must move as a whole into the DONE lane to deliver value for us.
This approach ensures that the TODO lane remains clean. This also makes sure that the focus remains only on the subtasks within the story that gets worked on. You could also say that the lane to the left of TODO on the board represents the sprint backlog. And we only pull in new work after committing to the part we are going to develop next.
When we are going to work on a task we physically move it to in IN DEV. When the subtask is done we remove it from the board. We also put our name tag at the subtasks we are working on. We may work on more then one task at a time if we see that the work is overlapping to much for example.
In the image above, we are just finishing work on our third story. The developers chose this story over the second priority. This was because it delivered more value at that moment. This decision got made due to sickness of one of our senior developers and a short holiday break of our PO. The morning that this photo got taken, our PO provided us with more details about the second story. This allowed the Developers to break it down into workable items/tasks.
Blocked stories
If stories are in the testing lane on the board after completing a new sprint. And this story was not a part of the current sprint we mark it blocked. In this case, we marked the story with an exclamation mark. We still focus work on this story of course. We still strive to move it forward, but sometimes it takes more time to move a story to the right. We may have to call in the help of the PO to move it forward or discuss with the stakeholders about its value.
This blocking state can get caused by an external factor, such as the task/story not getting tested. It can also be a quality issue where bugs keep coming up. And we are not being able to deliver the required quality until this gets fixed.
Every blocking story gets valued again at sprint planning. So we can determine if it is still going to be a part of the new sprint planning.
We can only have blocking stories in test the way we work. That is the moment we thought we delivered the value. This value is then already present in our release cycle cause we found it to meet the DoD.
This is also the part we focus on the most at this moment. Getting more quality before we move something in test. We only need our infrastructure to work along with that. And that is another topic we are working on. We are going to work with Kubernetes and this will solve most of our problems with the release cycle.
Finishing: IN REV & IN TEST
After all the subtasks get done and the whole story gets tested local by the developers. Only then the third story may move to the IN REV(iew) lane.
It is then reviewed by two developers after which it can move to the IN TEST lane. only after a positive review of both ofcourse. One exception is also that it may move on after getting reviewed by one developer and being 24 hours later.
This works for us cause we are a team of 4 and not everyone is available always and we also need to get confident and move on.
We currently have two testing environments, 31test and 32cur.
As explained already we are working on switching to automated DevOps with Kubernetes. This will make the way we work to the testing lane a much more automated experience. Another benefit is that this is also going to deliver more quality.
Finally DONE!
The DONE lane is split up for reasons i will explain below. Completed increments that are not yet deployed live are on the board in the "DONE not yet released" lane. This part of the lanes is the only lane that does not get emptied by the end of every sprint.
These items in the "DONE not yet released" lane need to get released of course. But that doesn't always happen immediately. For example: we need to communicate about the changes before releasing them. Another example is when the specific feature is set to go live on a specific date.
As Developers, we do need to keep monitoring when these updates go live of course. Bugs may arise so we need to know what is released and what isn't.
This also keeps a healthy discussion going about development done but not yet released. Having this visible adds to the transparency of what we are doing.
The released section under DONE means of course the item is live and fully deployed. This part of the lane gets cleaned every sprint. The items done here are being versioned after every sprint to keep track of progress.
Subtasks and visibility
We are still struggling with subtasks that are done. We want to keep them for a while for transparency it feels better to move a subtasks first after finishing it. This feels better then immediately removing them from the board.
We are currently discussing different variants of our board. We might create a space under the lanes where all done subtasks will get placed. Until the Developers decide to remove them of course. They are in charge of the readability of the board.
We are testing three different versions of our whiteboard at this moment. I will come back to these findings later.
Something about Jira
We dont have a rule to add subtasks in Jira. As a matter of fact i rather not see them in Jira. I use that mostly as my backlog and versioning system. Subtasks dont add any value for me in Jira until they get split from a story and become a task themself.
We do track and plan the whole sprint in Jira. But that is on a global level. The work done is mostly visible on our whiteboard. Stories of course move in both places. The board and Jira need to be in sync on the stories to be able to do my versioning and such.
If a Developer wants to add a subtask or needs to have a discussion about it we of course add the subtask to Jira. This way we can manage the discussed outcomes and discuss about them later on. This mostly happens on the parent story of course. But it isn't impossible to have a discussion you want to register at a subtask at some point. We dont encourage it but we also dont forbid it.
Conversation
If i want to know where we are in our sprint i really have to walk to this board where the Developers also work. One benefit of this is the conversation that starts between the Developers and me as a PO. The developers see that I am available and I of course carefully choose the moments to walk in.
You do need to look out for disturbing the Developers to much and trying to track work to often. There is a balance in when you walk up there disturbing the developers with your presence.
This talk is often about things they were already going to ask today. Because they see I am available to them it is even easier to approach me in that moment and verify that last thing.
You do need to keep in touch with your Developers as a PO during sprints. Preferably even on a daily basis depending on the stories within the sprint. You are not just there to start and end the sprint. That isn't a collaboration.
