Columns vs Tasks
Hi all,
The scrum guide says that the sprint backlog is a list of tasks (or "plan") to achieve the sprint goal. And my understanding is that tasks shouldn't be more than a day in size. I really like this idea; it allows a nice burndown against the ideal burndown line, gives good transparency on what needs to be done and current progress and also helps with the daily scrum as the dev team can discuss which day-sized tasks they're aiming to complete. All good things.
Currently however, the team I have inherited is using columns (e.g. in dev, in code review, in qa etc...) and stories. No tasks. Their argument is that this does give transparency as anyone can see the progress of each story, and that no one has ever asked for a to-the-day view of what the current state of the sprint is. My view is that it doesnt accurately reflect the progress of each story as you dont know how many days a column will take, or how much time it has currently taken. Also just signing off stories gives a horrible burndown line.
Im just wondering if other scrum masters have come across this and what their views are on this matter.
Their argument is that this does give transparency as anyone can see the progress of each story, and that no one has ever asked for a to-the-day view of what the current state of the sprint is.
During the Daily Scrum, how do the team visualize and develop their plan for the next 24 hours?
They pretty much just talk about what they're going to be doing with each story. E.g. "I'm going to writing the <whatever> for story x. It should be in qa tomorrow"
If external stakeholders are satisfied with the view that they have over the Sprint Backlog, the Development Team can track their progress on work, and the Development Team is able to hold an effective coordination and replanning at the Daily Scrum, then how is their current method not giving an accurate representation of the work?
Why does it matter if a story takes 1 day or 3 or 4 days or even 5 or 6 days to progress through the columns? Is the team able to identify and talk about work that is progressing slowly or at risk of not being done by the end of the Sprint and handle these cases?
Why does the burndown chart matter more than achieving the Sprint Goal or delivering value by getting useful, valuable Product Backlog Items to done and either demonstrated or deployed?
If this is a valid way of working, then why does the scrum guide explicitly talk about creating a plan out of units of work, each a day or less in size.
The scrum guide is pretty lightweight, so you would assume that every word in it is super important. If the above isnt an important aspect of scrum, then why would the creators of scrum bother to mention it?
If this is a valid way of working, then why does the scrum guide explicitly talk about creating a plan out of units of work, each a day or less in size.
I don't believe it entirely supports your point. The closest I could find is:
Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.
I would say that this makes it optional or advisable to break down work to such a size, but not mandatory. One could consider what benefits are lost by not decomposing work to such a size, but if there is no clear reason for doing so, there might not be anything to gain by challenging the Development Team in such a way.
It's also important to consider that tracking a story from left to right does provide certain benefits, and if that's the actual workflow, visualizing the Sprint Backlog in such a way could enable greater transparency of value creation, context switching, bottlenecks, and other impediments to progress, than breaking items into arbitrary lumps of work.
Furthermore even the advice in the Scrum Guide steers clear of suggesting whether such small items of work are tasks, stories, or even transitions of a single column in the workflow.
They pretty much just talk about what they're going to be doing with each story. E.g. "I'm going to writing the <whatever> for story x. It should be in qa tomorrow"
Does that really allow them to inspect and adapt their plan for meeting the Sprint Goal as a team?
If so, it would suggest that the work being undertaken is largely predictable, and that the team are indeed able to manage development risk with a Sprint backlog of relatively coarse granularity.
I agree with everything that has been said and I'm going to suggest that you may be trying to do something that could cause more harm than good.
The situation you describe sounds very much like they have implemented a Kanban board and are using that to manage their work. I honestly see nothing wrong with it and in fact have used it for a few of my own teams. It has helped them to visualize their workflow and gives "outsiders" an ability to actually see what kind of work is being done. If the team feels it is effective for them, why as them to change?
Using Kanban and Scrum together work really well. I think that instead of trying to get them to change something that is working for them, you may want to try to help them. Look at the Scrum with Kanban guide an see if you can find ways to help them.