Decomposing a User Story involves taking the result your user is looking for (stated as a User Story) and breaking it down into a number of tasks that the team can work on individually. Here are five tips I have found to be very useful:
1) Decompose User Stories into tasks as a team
Group planning is a cornerstone of Agile development. Though it may feel inefficient at times, the benefits are well worth it. See my previous post: Agile Planning: Plan/Estimate As A Group, Really? for more information/details.
2) Attempt to size your tasks to take one team member between 1/2 day to 3-4 days to complete
Motto here equals: Allow a “Race to Done” situation
Creating tasks that are smaller than a handful of hours end up taking to much time administratively to create/track/update/etc. Tasks that are larger than 3/4 days (some would say that is too big, but teams I have been on have found it to be workable) really should be broken into a couple of tasks if possible. They just take too much time to be able to race to done effectively.
3) Create tasks that result in a deliverable unit of work when completed
When decomposing a user story, be sure to break the story down into tasks that can be completed in a small amount of time (Point 2) but don’t focus on the time so much as ensuring you are creating tasks that result in a deliverable unit of work.
Don’t break down a ‘Maintain User’ feature into (like you might have in the past):
- Build the UI
- Build the biz logic
- Build the data tier
Instead create vertical slices of functionality when possible:
- Implement Add User
- Implement Edit User
- Implement Delete User
- Implement Add/Edit/Delete User Automated UI tests
- When a team member takes on the ‘Implement Add User’ task, it’s a contained unit of work, straight forward to know when completed, and also not dependent on other tasks being completed to be able to be tested (like Build UI/Data tier/Biz logic all are dependent on each other to deliver functionality to the user).
4) Don’t get caught deep diving into the details of each task
This is more difficult in practice than in theory. Knowing that task estimation is just around the corner for the team, it’s natural for a experience developer to what to define all details possible, down to ‘how many stored procedures are we going to be creating’. This, in theory at least, helps ensure the estimation process will be more precise. I don’t buy into this theory, at least not from a time invested by the team to get this extra level of preciseness. Certainly attempt to ask the functional questions when decomposing a User Story, so hidden functional ‘gotcha’s are uncovered, but also realize the team is just defining/sizing effort at this point, not writing up a ‘development specification’.
5) Ensure testing/automation tasks are included
On the teams I have worked with over the past years, we have always had a group of professional Quality Assurance Analysts. Our Scrum teams are no different so these types of tasks don’t usually get forgotten, but for the many teams that don’t have QA pros integrated into their Agile teams, I can imagine this to be something missed. A motto of ‘get the functionality to the user as quick as possible’ would seem to lead to that. Just because the team is Agile, doesn’t mean there isn’t any testing that should go on! Automating tasks where appropriate is also very important, given the high amount of regression testing that is needed when sprinting via 2-4 week timeframes.
Next up in this series, group estimate via Planning Poker.
