Story Tasks need Systems Thinking
Ron Jeffries recently wrote about his issue with story tasks – “We imagine a smooth set of tasks, but we wind up with too much work on one task, too little on another… integration is a nightmare, and what we get doesn’t turn out so smooth“. This is a phenomenon I refer to as task fragmentation – when a story is broken down into a series of tasks, the tasks are poorly-defined and take on a life of their own – and this problem can be very prevalent in Scrum.
When splitting a story into tasks, it’s important to remember motivation. Regardless of agile flavour, we split stories into testable tasks so that developers can continuously check in production-ready feature increments, and testers can continuously contribute feedback on the current story. If a task is not testable, how can we verify the task is complete? Is it really a task?
This is where Kanban-style practices can be extremely helpful. We can use systems thinking to consider the organisation as a whole:
- How is this task testable by testers, and then the Product Owner?
- Where might this task stall on its way to Done, and what might the ramifications be?
- Once this task is complete, which other story tasks can be pulled further down the “production line” of developers and testers?
- How does this task directly contribute to achieving the business value we seek?
In my experience, the above approach is far more successful than splitting stories to parallelise work (danger of losing business value context) or to provide fine-grained hours-based estimation (misleading, inaccurate information). It’s about the business value, stupid!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)