BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Repetitive Tasks an Agile Smell?

Repetitive Tasks an Agile Smell?

This item in japanese

MouseMakingstories a vertical slice of the system under development is a well known approach to ensuring that the stories aren't driven by the application architecture. Team’s are typically warned by their trainer/coach that slicing stories horizontally leads to a number of problems: presupposing the architecture, over production (or gold plating) as we write the functionality we think we will need and most importantly no visible progress or business value for the customer. For more details see Mike Cohn’s User Stories Applied.

Antony Marcano brings up an interesting twist by suggesting that tasks are often repeatitive horizontal slices of stories for example: "Add x to the Model", "Change View". In the traditional Scrum/Agile approach teams estimate the number of task hours for the sprint and then track them in a Spring/Iteration burndown chart. Antony points out that this is not a real measure of progress in terms of working software.

Others have responded to this problem by suggesting: Burn Stories Not Tasks and Track Velocity, Not Time Spent on Tasks.

Antony proposes we track the acceptance criteria successfully implemented for each story. To do this we need to change the acceptance criteria from vague statements to verifiable examples: “Must have a link to save the profile” –> “Should create a new profile”. Once the acceptance criteria are testable we can track whether there acceptance tests for the criteria and whether or not they pass.

Jason Gorman has noticed the same problem noting that task tracking can lead to a false sense of completeness:

“tasks are the "how" and it's quite possible to be 90% of the way through the tasks for a user story and have delivered nothing of any value to the users. So planning and tracking iterations through tasks can lead to the notoriously misleading "90% done" syndrome”

Jason’s approach is a solution the problem Antony describes. Jason would have the team estimate the complexity of each of the tests for a story. The team tracks the number of acceptance test points delivered.

Any way you slice it the consensus is that tracking task hours is passe and instead we should find a way of measuring value delivered to the customer.

 

 

 

 

BT