Task Lists:
Generally scrum teams define user stories in such a way that they can be completed within 5 scrum business days by one or more team members. And these user stories are broken down into tasks, may be to a component level that details each of the individual elements of the software architecture required to deliver the feature of the product.
Below are some of the examples of task break down for a user story.
- Design for the user story – This task specifies white boarding or group discussion regarding the implementation of the user story.
- Implementation of the user story – This task could specify all the required interfaces and methods to implement the story. This task can be again subdivided into multiple tasks if the size of the task seems large.
- Write unit tests – For any development, unit testing is mandatory and it helps to remove the most number of bugs from the code.
- Code Review – Every line of code delivered as part of the project should be reviewed by team mates.
- Bug fixes – Code may have some bugs which are identified during peer review or in later stages of testing. Appropriate time should be allocated to fix these bugs.
- Documentation – Prepare documentation for the project that contains information like installing the product and reference to the usage of the product.
Size of the task should be small such that each task can be completed with in one Scrum day. Dividing the tasks into smaller sizes has many benefits as listed below.
- Team members can use these tasks as deliverable i.e., they can specify what they are going to deliver instead of what they are going to do
- Tasks will be easier to estimate
- Team members can easily complete these small chunks of tasks without any problems and deliver them. This thereby increase the confidence levels of the team and increases project progress.
Definition of Done:
Team defines “done” with the guidance that it should include everything required to get that feature “production ready”. In other words, the team agrees on a list of criteria which must be met before a “user story” is considered “done”. At the end of the sprint, team checks whether these criteria was met or not, if it wasn’t met then the work is not counted towards that sprint’s velocity.
For a software module, below are some of the things on task lists that are said to be done:
- Code is signed off as meeting technical standards
- Automated acceptance tests written and passed
- Interfaces operate as designed
- Completed exploratory testing and documented the results
- Deployment scripts/instructions updated if required
- Bug-free code
- User interface complies with corporate standards
Below is an example:
References:
[1] PracticeAgile Solutions Private Limited: Template of task breakdown for a user story. (n.d.). Retrieved October 11, 2014, from http://www.practiceagile.com/2010/08/template-of-task-breakdown-for-user.html
[2] Sprint Planning. (n.d.). Retrieved October 11, 2014, from http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-4-sprint-planning-tasks/
[3] How do you define “done” on a project or task? (n.d.). Retrieved October 11, 2014, from http://pm.stackexchange.com/questions/2533/how-do-you-define-done-on-a-project-or-task
[4] Definition of Done. (n.d.). Retrieved October 11, 2014, from http://agiledictionary.com/8/definition-of-done/
[5] Definition Of Done. (n.d.). Retrieved October 11, 2014, from http://guide.agilealliance.org/guide/definition-of-done.html
Sravan's Blog 
The blog started with the explanation about user story and task lists. This is an ideal way to begin a topic, as it helps the reader get better understanding of topic internals upon proceeding further.
Breaking down the user story into tasks is well explained with the help of an example. The pictorial representation of ‘to-do’ tasks and ‘done’ tasks explained the concept of task lists clearly. Good information is provided on the reasons for which task lists are important for a project.
LikeLike