This post originated from an RSS feed registered with Agile Buzz
by Simon Baker.
Original Post: User stories and tasks
Feed Title: Agile In Action
Feed URL: http://feeds.feedburner.com/AgileInAction
Feed Description: Energized Work's blog.
The process of breaking down a user story is important because it helps me think about how I'm going to build the functionality. Many people disaggregate a user story into tasks and then estimate them (usually in ideal time) because they're smaller units of work and can be estimated with less inaccuracy. Then they total the task estimates to obtain a better indication of how long it will take to complete the user story. Tracking each task's remaining time feels like micro-management, so I don't it anymore. I'm only interested in tracking the number of running tested features. I want to know how many user stories are passing all their FIT tests.
When I start developing a user story, I like to break it down into vertical slices of functionality that I note on the back of the story card. I try to define these slices in such a way that I can build them one after the other (refactoring in-between so they fit together with the latest extending its predecessor). It's similar to erecting a fence. This approach allows the customer to see and play with the evolving functionality and to provide feedback, which I take into the next vertical slice.
As I work on a slice of functionality using test-driven development, any tasks identified are written down as notes on a piece of paper or an index card. This task-list is just an evolving to-do list for the slice. As a simple memory aid used in conjunction with test-driven development, it guides the way and reminds me of what I need to do. These tasks are very granular and because they're noted just-in-time they're not situated very far away, perhaps only minutes or tens-of-minutes away. Consequently, it doesn't matter where I write them because they'll be crossed-off soon enough when they're completed.
It doesn't make sense to track the time remaining to complete one of these tasks because it's too small. Tracking running tested features focuses attention on the development team (and the user stories that they've committed to delivering) rather than on individual team members. Focusing on the team as a whole helps them to recognise their collective accountability and to develop their collective responsibility. This helps a team to become self-organising.
Previous Topic
