The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Why Stories and Not Tasks

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Keith Ray is multi-platform software developer and Team Leader
Why Stories and Not Tasks Posted: Feb 16, 2005 8:16 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by Keith Ray.
Original Post: Why Stories and Not Tasks
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
Latest Agile Buzz Posts
Latest Agile Buzz Posts by Keith Ray
Latest Posts From MemoRanda

Advertisement

Why does XP do Release Planning and Iteration Planning using Stories (user-centered mini-use-cases) rather than tasks (technically-centered things to do)? Because it's fairly easy to come up with a mostly-complete list of user-centered stories for a piece of software. You can track their completion, and when all the stories are done, you're done writing the software, even if the estimates for the stories varied wildly from the actuals.

On the other hand, at the beginning of a project, it's much more difficult to break down a project into technical tasks correctly, and to come up with a mostly-complete list of tasks. We've all had the experience of discovering lots of tasks during the project that were not anticipated at the beginning. The problem of poor estimates is compounded by our lack of perfect foreknowledge of all the tasks to do.

By waiting until a story is scheduled in an Iteration Planning meeting (or afterwards during the iteration itself), to come up with tasks for that story, we enable the Lean [pdf] practice of deferring decisions "until the last responsible moment". The decisions for those tasks will be better, in the light of previous development and the situation as it stands "now", than if all technical decisions were made at the beginning of the project -- when we're most ignorant of what technical choices will work or fail.

See Alistair Cockburn's "moving" example of tracking the estimated number of boxes to be packed versus tracking rooms to be emptied.

See also Ron Jeffries on Big Visible Charts and Running Tested Features Metric.

Read: Why Stories and Not Tasks

Topic: Agile vs. RUP - Practicing Resonance: Part 1 Previous Topic   Next Topic Topic: www.softwarewithstyle.com up

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use