As was outlined in earlier entries; the sprint backlog contains requirements. Requirements could mean expected outcomes of pressing a button, what the GUI should look like, or multitude of other things. The requirements themselves, cannot always be converted straight into functioning features, this is why we create task lists.
Task lists are essentially the way agile teams take a big idea, such as a feature, and break it down into smaller and more specific detailed tasks. Interestingly this breakdown can be done in a recursive fashion, meaning that if the team breaks down a task and finds that it is still too broad of an idea to translate into code, they can do it again and again until it is. All that matters is that, however many tasks you have, completing them eventually results in the original user story or requirement. Kelly Waters, author of the book All About Agile and esteemed member of the agile community in the UK, notes that it is important for tasks to be measurable, such that the task is a description of what will be delivered versus what will be done.
Now we have a list of tasks that need to be done, this is where we run into another would-be obstacle. When someone, say a programmer, checks off an item as done; what did he mean by that? This question may sound silly, however I assure you that it is very relevant. The word “done” can be interpreted by two individuals differently. Person A’s definition of done could entail things aside from implementation, like testing, whereas person B’s definition may not include such things. Therefore, it is important to creating a definition of done (Waters, 2007), when creating tasks on the task list such that the team can feel confident that they are all on the same page when an item gets marked as done.
So how do we go about creating a definition of done? The tasks themselves, as stated earlier, should be descriptions of what will be delivered. So a good question to ask ourselves should be, can we ship it as a deliverable as is? This question brings up a couple more: Has the client approved it? Has it been tested? These questions could vary greatly depending on the organization in which this project is taking place (Waters, 2007), but the overall the definition of done should be comprehensive enough such that your team can feel confident that they will not have to waste time coming back to this feature in future and can move on to the next feature.
Agile Task Table [Image]. Retrieved October 12, 2014, from: http://bit.ly/1ttEIXM
Checklist [Image]. Retrieved October 12, 2014, from: http://bit.ly/1z76L2X
Eberlein, A., & Leite, J. C. S. P. (2002, September). Agile requirements definition: A view from requirements
engineering. In Proceedings of the International Workshop on Time-Constrained Requirements Engineering (TCRE’02) (pp. 4-8)
Waters, K. (2007, April 8). Agile Principle 7: Done Means DONE! Retrieved October 12, 2014, from