Agile Zone is brought to you in partnership with:

Steve Smith is an Agile consultant and Continuous Delivery specialist at Always Agile Consulting Ltd. An XP / Lean developer with 10+ years of experience in enterprise software development in Britain and New Zealand, Steve favours practices such as Pair Programming and Test-Driven Development to build quality into software products. As an early adopter of Continuous Delivery he has overseen transformation programmes in multiple organisations to reduce lead times and increase product revenues. Steve is a co-author of the Continuous Delivery and DevOps book "Build Quality In", a co-organiser of the monthly London Continuous Delivery meetup group, a co-organiser of the annual PIPELINE conference, and a regular speaker at conferences such as Agile On The Beach and QCon New York. Steve blogs at Always Agile Consulting and is on Twitter at @AgileSteveSmith. Steve is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

Story Tasks need Systems Thinking

  • submit to reddit
Story tasks lacking systems thinking give a false indication of progress

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!

Published at DZone with permission of Steve Smith, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Peter .. replied on Thu, 2013/03/21 - 5:08am

Your link Kanban-style practices,, appears dead. I'm redirected to some landing page.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.