Agile task lists
After creating a product backlog from user stories, the next step is all about how to bridge the gap between having a plan, and starting real concrete work on the project. In order to do this, we need to plan out the sprints in detail, including what needs to be done during the sprint, which can be accomplished through sprint backlogs. Similar to product backlogs, sprint backlogs are a more condensed iteration consisting only of work that needs to be done during that one particular sprint. Within these sprint backlogs, there are tasks. “Tasks provide a way for the team to agree exactly who is going to do what to complete the story. Tasking exposes dependencies within the team as well as bottlenecks, resource availability, etc” (Leffingwell, 2013). This can improve and streamline the team by supporting and teaching the weaker team members after determining who they are. Also, agile task lists make the workload much easier to handle and much more organized.
For example, my group utilized sprint backlogs (Figure 1) recently to track our work on the STEM NOW website. We split up user stories into smaller, more doable tasks that are trackable. Our most recent iteration of the sprint backlog included tasks like coding the headers, footers, and creating specific pages. The Agile style of product building tends to focus on putting similar tasks together, in order to build a potentially shippable product out of what was completed. Akin to how product backlogs are timed, sprint backlogs are also measured in estimated and actual hours worked.
This agile task board shows what tasks are currently in the list and their progress. It is an easy way to display to those not involved within the development of the project to understand how far along the product is. Task lists show transparency on what is currently being worked on to those outside of the project, and easily shows sprint managers who is slacking and who is on track.
What does “done” mean?
Everyone has their own definition of done. However this would not cut it in an agile setting. An agile team, from the product stakeholders to the development team, must agree on what “done” is. In an industry setting, done is not only just working code. There are multiple steps that need to be taken, such as commenting the code, making sure that multiple eyes have checked it, and meets industry standards, has complete documentation, and is agreed upon as finished by everyone on the team.
Hannington, F. (2013). Agile Task Board. Can I Be an Agile Technical Communicator When My Team Is Not?, Techwhirl. Retrieved from http://techwhirl-1.wpengine.netdna-cdn.com/wp-content/uploads/2013/05/agile-_task-board.jpg
Leffingwell, et al. (2013). Tasks. Scaled Agile Framework. Retrieved from http://scaledagileframework.com/tasks/
Waters, K. (2007). Step 4: Sprint Planning (Tasks). All About Agile. Retrieved from http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-4-sprint-planning-tasks/