Here’s a tip for scrum teams. You are almost certainly using a task board. If not start today.
That task board typically consists of the standard TODO, Doing, Done style. Sometimes you will see the Doing column divided up even further – some mature teams realise that but a lot don’t so here comes the tip.
In doing sprint planning or planning for a User Story the team identifies a number of tasks required to complete the story. For example, perform detailed analysis, code the UI, code the business logic, perform testing.
It turns out to be quite a laundry list of tasks. Within that list is always a pattern. That’s right always. All your user stories almost certainly involve a component of analysis, coding and testing.
So the tip is to make that visible and stark to everyone viewing your board. Evolve from the three column format of ToDo, Doing and Done and divide that Doing column into Analysis, Code and Test.
Whilst your at it, define some common policies for those columns. For instance for coding – code and test UI, code and Test Business Logic layer and so on so forth. That’s called your Definition of Done.
What does this do for the execution of the sprint? Here are several things it can and should do.
- Sprint Planning becomes more focused on asking real pertinent questions about what’s coming up rather than diversion on getting the laundry list together. You could really ask the what if questions of the Product Owner and making a deeper start in technical implementation details and discerning the risky parts of the work.
- Make the flow of work more visible. This will increase the effectiveness of daily standup. Speaking to the cards on the board and seeing where they are at, how long they have been in a part of the workflow causes more transparent and focused discussion of the work. Of course the team should be willing to discuss the reality of the situation and some will refuse to do that even when it’s staring them in the face. Note: This is when the real rubber hits the road – the Scrum Master, Agile Project Manager will be willing to seek out help the team discover the causes and deal with the organisation impediments.
- Show the real time for each part of development. This can help the team improve on specific problem areas. Because there is real data for each point of the process, the team can choose where to focus their improvement efforts to decrease the overall time to deliver.
So you may ask. Is this Kanban. The simple answer is no. A Kanban System has more components – most importantly WIP limits on workflow steps. However use of a these ideas more readily found in Kanban systems will still create visibility. Evolution to more flow based systems could be an end result or perhaps just a hybrid like Scrumban.
So avoid the workflow masquerade. Make those tasks into workflow and get on with real work.