Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Chris Sims on Jan 12, 2009
Developers commonly break user stories into tasks to facilitate distributing the implementation work across the team, and allow tracking of progress at a finer level of granularity. Unfortunately, a story can explode into a list of non-trivial tasks so large that the story is not deliverable by the end of the iteration. Ron Jeffries suggests: Do stories as a unit, not broken into tasks.
In order for this to work, the stories need to be small enough that the team can understand and estimate them well. One approach to decomposing a story is to list the acceptance criteria, and then look at each of these and find the ones that can be stories themselves. If the particular acceptance criteria adds some value to the product, is user visible, stands alone, and is testable, then it is a good candidate to become its own story.
Many teams have specialists that focus in particular areas of the product or the underlying technologies, making it difficult to give a whole story to an individual engineer. A long-term solution is to cross-train developers such that they can work in the various parts of the system and with all of the needed technologies. This creates a team that is versatile and reduces the organizational risk of loosing 'the only person' who is competent to work in a given area of the system. One way to get the work done now, while moving in this direction, is to use pair programming. The person who 'owns' the implementation of the story pairs with the people who have the needed expertise, in order to deliver the whole story.
Ron recommends: "Burn stories, not tasks." When tracking (burning) at the task level, developers can 'do their part', finishing many tasks, without any user functionality being delivered. If the team only tracks story completion, then developers only get the warm glow of finishing something when a story is complete. This encourages a more valuable notion of 'done.'
Do you agree with Ron's approach? Leave a comment and share your views.
Regaining control of the data centre
Technical Debt and Design Death
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
I've experienced a team that decided to focus on tasks rather than stories, and it wasn't pretty. As mentioned in the article, what occurs is a lot of activity but very little real progress from the business perspective.
That said, tasks are good. They give everyone an idea of how much work is involved, and provide a sanity check for story estimates. I had a business analyst comment once that she was surprisedby how much work went into delivering software after she saw a task list created after Iteration Planning. However, using tasks as a measurement of progress doesn't work.
Dave Rooney
Mayford Technologies
+1 from me... Tasks estimation and tracking progress using story tasks almost alway leads to tasks becoming pseudo user stories within large and overestimated real stories.
Besides how do you estimate tasks? When estimating stories we encourage developers to use points and to show only relative size of a story within other stories. You can do that because all stories are functionalities from a user point of view, so you can alway say this story might be 3 times harder to implement that the other one. I think it's much harder to do with specific, usually technical tasks - you start judging between activities of different type, for example implementing some component and designing user interface. I think estimating tasks quickly falls back into estimating in man-hours, people micromanagement (as resources) and tracking people instead of real progress.
Surprisingly when implementing our tool (tinyPM) we found the feature request "Tasks estimation" to become the most wanted one, while we want to encourage our users to rather split stories into smaller functional parts and use tasks for stories as some kind of to do list for developers. This way we always know what this story consists of, but still story is done only when all the tasks are done.
Marcin Niebudek
tinyPM Team
The point is that you should measure delivery by function delivered and accepted. If you break a story into tasks, and the tasks have a measurable, testable deliverable, then it's okay to work by tasks. But then, those tasks aren't really distinguishable from stories, as Chris correctly notes. If you break a story into tasks that aren't measurable and testable, then don't measure them. Similarly, a story should have a measurable, testable chunk of business value that can be accepted by a customer. If it doesn't have one, it should be refactored somehow to do so.
Either way around, what you should measure is the acceptance of a piece of business function by the customer rep, whether stories, tasks, or fizbins.
We have noticed this behaviour in my team, but the reality is that we're often working on fairly complex (read badly designed) legacy systems where the 'cost' of implementing a story or two is so big that an entire sprint is taken up with only 1 or 2 stories. We need the visibility of progress that Scrum affords but unless we breakdown into tasks and cost associate these, we lose that in the burndown. We know it's not the ideal but cant see a way to have our cake and eat it?
I guess I have two thoughts.
First, if the problems are telling you that you can only do one or two stories per sprint, it might be you should believe them. There's nothing wrong with two stories per sprint, if the result is predictability and repeatability.
Second, if for some reason, whatever reason, that isn't acceptable, maybe you should change the duration of your sprints a bit. There's nothing magical about a 3 week or 1 month sprint: would you get better results if you did two week sprints and one story per sprint? Or six week sprints with four stories?
We have practiced the simlar appraoch. But we also added tasks. It make sense we don't need tasks when we have clear acceptence criteria.
(Not sure how I missed this earlier, but better late than never).
I totally agree that micro-tracking anything more granular than stories is missing the forest for the trees, and a ick recipe. I had posted about this here, check it out.
Cheers
MB
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
7 comments
Watch Thread Reply