In a few Agile/Scrum training and coaching engagements that I have been involved with, I shared the template of ‘task breakdown for a user story‘ and found that teams find it very useful. This task list also defines ‘done’ criteria for the story. I am sharing the same template with everyone in this forum for your reference.
As a rule of thumb, I recommend scrum teams to define a user story that can be completed in 5 Scrum working days by one or more members. Also, as a rule, the task should be granular enough to be completed in 5 hours max (1 Scrum day). Defining granular tasks enforces discipline among team members to develop and deliver small chunks of functionality everyday to mainline source repository instead of delivering a large chunk of code together which is more error prone.
Here is a list of task breakdown for a user story. Please note, this is a reference list and all tasks listed below might not be applicable to each story.
- Design for the story – This task is specifically for white boarding or group discussion on how story will be implemented.
- Implementation of the story – This task could include defining the interface and methods needed to fulfill the story. There can be multiple tasks for this type.
- Write unit tests (TDD) – I encourage and enforce teams to write code using Test Driven Development (TDD). For any coding story this task is mandatory.
- Write Acceptance tests – This task is used to write the automated acceptance tests that will help with the story acceptance.
- Non functional requirements (NFR’s) – For each story, quality attributes like security, performance, usability, testability, maintainability, extensibility and scalability must be considered.
- Code Review – As a rule, every piece of code delivered to mainline repository should be peer reviewed.
- Code Re-factor – Beautifying the code by restructuring. This task should be included for each story to avoid a complex mesh of code later.
- Mock interfaces – At times, development can take a while to produce real implementations of the interface. In such cases, mock interfaces must be provided to help QA engineers with a head start.
- Exploratory testing -Perform Ad-hoc testing for the story. This could include performance testing, scalability testing, etc.
- Bug fixes – Depending on the story, appropriate time should be devoted for bug fixes
- Bug verification – Depending on the story, appropriate time should be devoted for bug verification
- Demo – Internal demo of the story within the team. I like to add this task as it helps Scrum team members to be on the same page. After the daily standup, if a story is complete members can take few minutes and educate others on the implementation of the story.
- Update Wiki or document repository with the design and findings of the story
- End user documentation – This is for updating the reference guide, Install document, etc, if applicable.
There could be other tasks for building on the CI server, Integration testing, etc that might have to be included based on your environment. If you can think of any additional tasks that I am missing from the above list please share the same so I can update the above template.
Anonymous
Hi Hiren,
This is an excellent breakdown. Thank you. I'm wondering if you have a live example that you can share, minus anything proprietary of course?
Thanks,
mike
Ilja Preuß
Thanks for publishing your list. It's thought-provoking.
Frankly, I'd be wary of showing this list to a team new to Agile. When coaching a team, I'd also try to stress a break down in terms of functionality instead of a waterfallish break down. Which doesn't mean that a team shouldn't find some standard tasks they always need to remember (such as acceptance testing or documentation), but I'd prefer those to emerge from conversations in the team instead of from following a template.
I'm deeply puzzled by having different tasks for implementation, TDD and refactoring. TDD is a way of imlementing code, which includes a refactoring step, so I have no idea how you could separate them into different tasks.
I also don't understand why I would want to have a bug fixing or verification task, and suspect that it is a process smell.
The last team I worked with always had "Write Acceptance Tests" as the very first task, and "Run Acceptance Tests" at the end (just before "Documentation").
Pascal Thivent
Interesting. But I prefer to derive what has to be done for each story from the Definition of Done (which typically includes things such as acceptance tests pass, code is tested, code has been reviewed, no increase of technical debt, etc).
admin
Pascal – Thanks for your feedback.
Fair enough – I think we are talking the same things. I won't expect engineers to close the tasks without Acceptance tests passing or without reviewing the code. What I am merely suggesting is listing down all tasks for the story that helps meet the Done criteria for the story so nothing goes amiss.
admin
Ilja – Thanks for your feedback.
The reason I like to separate TDD and Refactoring is because it happens in 2 phases. Phase 1 is to implement code with simple internal design for the code and simple possible implementation to get the test to pass. And, phase 2 is to Improve the design without introducing new behavior. What I have noticed is developers have tendency to skip phase 2 thinking they will revisit later and re-factor the code which builds the technical debt. So defining a separate task for Refactoring helps. However, if you have seasoned and disciplined engineers then you don't need to call out refactoring task separately.
The bug fix and bug verification tasks are necessary evil to account for time spent by team each sprint. What I like to do is create 2 tasks of 0h each to begin with and I request engineers to update the hours they spent fixing defects and verifying defects for each story. The data collected is used to better plan the future sprints.
I like your idea of first task being "Write Acceptance Tests" and last task being "Run Acceptance test".
Brad Barton
I tend to agree with Ilja. While a list like this might help the team to consider the collection of work that must be accomplished, I prefer to think of planning and tasking as something that goes a bit deeper.
In planning, I encourage teams to talk about the manner in which they can most efficiently accomplish this work collaboratively in the context of each story (and based on the realities inside their team).
I view the template approach as an ingredient list/recipe and the tasks as the thought that goes into making sure you and your shopping partner(s) get everything, get out of the store and get dinner made by the time the guests arrive. For example – one person grab the deli items, someone else get the dairy, and third grab produce. Someone will fire up the grill, while someone else is chopping veggies… (Forgive me if I've gone too far here)
Ilja Preuß
I guess you could call "write a test", "write production code" and "refactor" "phases" of TDD. But with proper TDD, those phases last only minutes, and are switched between dozens of times for the implementation of a story. I have no idea how you could make them into tasks, or how that would help beginners learn to do proper TDD.
Regarding tasks for bugs, I would never track time on a task level, but at story level at best, if absolutely necessary.
admin
Hello Ilja – Thanks again for the post.
In my past experience I have seen folks generating technical debt due to aggressive schedule and that's the only reason I like to call out the refactoring task. I agree with you that if TDD is done well these phases lasts only a minute – but this is not always the case.
Agreed – I meant to track time at the story level. i.e. If the scrum team spends 10 hours on fixing defects and for verification of the same I will like to see those 10h accounted for as this at a story level as it will help the team with proper estimation next sprint.
admin
There is lot of interesting discussion happening on this thread at scrumdevelopment forum.
https://groups.yahoo.com/group/scrumdevelopment/message/48184