31 Aug 2010 - 9
Template of task breakdown for a user story
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.