AGILE TASK LISTS
The first part of Sprint planning is about clarifying the requirements for the selected Product Backlog and the second part is focused on breaking the requirements into tasks and estimating the hours required to complete them. Once the budget is set for the sprint , the next thing to be done is to Break requirements into Tasks. All these tasks are then listed down and are know as “task lists” (Waters,2007, para 2).
Lets see how to put them in task lists :
Each of these tasks, especially development, may be broken down further. Maybe to a component level detailing each of the individual elements of the software architecture that will be required to deliver the feature of the product. Include all tasks necessary to make the Product Backlog item 100% complete that can be potentially shipped within the Sprint. Agree as a team on your definition of done, so everyone is aware what will have to be completed and included in the estimates. State the tasks as deliverables, if at all possible which makes it more measurable . Instead of describing what you’re going to do, describe what you’re going to deliver in task lists.(Waters,2007, para 10).
WHAT IS DONE IN AGILE ?
In agile development, “done” should really mean “DONE!”. Features developed within an iteration (Sprint in Scrum), should be 100% complete by the end of the Sprint. (Waters, 2007, para 1)
Too often in software development, “done” doesn’t really mean “DONE!”. It doesn’t mean it is tested or necessarily styled. And it certainly doesn’t usually mean accepted by the product owner. It just means developed.(Waters, 2007, para 3)
So, in agile development, make sure that each feature is fully developed, tested, styled, and accepted by the product owner before counting it as “DONE!”. And if there’s any doubt about what activities should or shouldn’t be completed within the Sprint for each feature, “DONE!” should mean that it can be shipped. One feature may rely on other feature(s) being completed before the product could really be shipped. But the feature on its own merit should be shippable. So if you’re ever unsure if a feature is ‘done enough’, ask one simple question: “Is this feature ready to be shipped?”. (Waters, 2007, para 5)
How did we decide in our implementation project that a task is actually “done”
Here is a list of 10 point checklist to tell that – (Waters,2007, para 2)
- Code produced (all ‘to do’ items in code completed)
- Code commented, checked in and run against current version in source control
- Peer reviewed and meeting development standards
- Builds without errors
- Unit tests written and passing
- Deployed to system test environment and passed system tests
- Passed User Acceptance Testing and signed off as meeting requirements.
- Any build/deployment/configuration changes implemented/documented/communicated
- Relevant documentation/diagrams produced and/or updated
- Remaining hours for task set to zero and task closed
An agreed team definition of Done is essential to working Agile !
1.Waters,K.(2007,October 11).How to implement scrum in 10 easy steps.All About Agile. Retrieved from http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-4-sprint-planning-tasks/
2.Waters,K.(2007,April 8).Agile Principle 7:Done means DONE!.All About Agile. Retrieved from http://www.allaboutagile.com/agile-principle-7-done-means-done/
3.Waters,K.(2007,July 07).Definition of Done ! 10 point Checklist.All About Agile. Retrieved from http://www.allaboutagile.com/definition-of-done-10-point-checklist/