“It is more important that you know what stories you can complete in an iteration than to be perfect in your decomposition of tasks” – Mike Cohn
I heard this statement early this week and it really resonated with me. I have always been a fan of “tasking enough to get working without perfection” and have always coached teams towards this goal. My reasoning behind this is just as I cannot perform BDUF (“Big Design Up Front”) for a given software product with real accuracy typically,
I feel the same about BTUF(“Big Tasking Up Front”) when it comes to decomposition of stories. While I think tasking is important for a team to have insight into the work to be done, I do not think the world will stop spinning and tend to agree with Mike Cohn that insight into the commitment and its completion is far more important than 100% accurate tasks. And if you are reading this line and saying “how will we gain our metrics”, I would say perhaps you are focusing on the wrong measurements.
Does this mean that I am saying “wing it” or dump estimates. No, I am not. Not at all. I think that decomposition of work is beneficial, not only to the team members but in completing the work. What I am agreeing to is just as we have accepted on the base level that we cannot fully design a system being built, I do not think that we can 100% accurately task the item being worked on. The core idea for me is whether or not the end goal, feature, story or whatever may be more important than this level of accuracy. I have yet to hear in any conversation with a team all work that has been done has been tasked and estimated. Everyone has a threshold. For many teams it is a split second measurement of the overhead of creating and estimating the task versus the effort in “getting the work done”. If it takes 2 minutes to do something and 4 minutes to task and estimate it. A 50% savings in time may push them to not define that task. Could they do it post work? Sure they could but updating work completed after complete seems counterintuitive and likely counterproductive as well.
What I am saying is that if you put good faith effort into decomposition of the items that you know you need to accomplish the completion of the work committed, you might miss some small things based on the degree of knowledge you have in the moment. It’s ok. The seas will not begin to boil and the clouds will not crash to the ground. But try and keep these things to the exception, not the rule. Do your best to identify what needs to be done and maybe even make a team agreement of when injected tasks need identification. Failure to do so can put a team at risk in making over-commitments and not having the data to understand why in a retrospective or just hiding work by working unrealistic hours to make a commitment fit into the sprint and hiding the work by merely not making it visible.
I suspect the likelihood that you have all forgotten some “product altering major issue” task is much lower. What you may have forgotten is some lower end tasks or some tasks that you know you have to do but they are much smaller in scope. Maybe they were emergent in the moment as you inspected and adapted the solution as it was built. And if you complete those tasks but forgot them, are the scrum police going to come and snatch you away?
Because the goal is the commitment is a whole, not the individual tasks. I would only be concerned about a team missing tasks when they begin failing commitments or I observe a team health impact to hidden work or defects. I suspect in this case, they just did not understand the work ahead of them and without good decomposition, they found a point in time where the work outweighed the team capacity.
So be mindful but also be aware that tasks are vehicles to complete ideas into working software. Be focused in creating them but also be realistic to know that there will be some that never get visualized. Observe for the onset of problems caused by this, not the applicability of a “rule” that demands compliance. Focus on the end value and mode the idea that breaking these larger ideas insto discrete parts reflect continuous progress on the journey to get there to the team.
Have a great day, a great weekend and keep getting more agile each and everyday!