In the world of development having a plan is important to help focus ideas. Having a plan can help direct work flows and generally make project with a lot of people easier to organize. If the plan is too rigid, that once a part of the project is finished that part is ready to ship it can hinder the projects work flow. In development ecosystems like agile plans or task list help guide teams towards a finished product. At the end of each sprint there is a retrospective, which in the team will put down a completed or “done” task. Tasks marked as “done” maybe finished but are not exempt from change.
The image from Henrik Kniberg slide show about agile development I think embodies the main idea of what an agile task list should be. It’s simple enough that it can change, without being to simple that nothing can be gained from it. It is also not so structured that nothing can ever change in it. The book “Agile for Dummies” by Scott W. Ambler and Matthew Holitza looks at the what agile developers can gain by implementing a task list. The authors look at things like “Tracking Velocity”, which follows the “Done Tasks” or the deliverable work. Handling Deliverable work allows a team to deal with small part of the over all projects and allows a set task to have a well-defined goal without having a strict overbearing plan like in waterfall(pp. 20-24). Since fluid nature of agile tasks allows the task to change throughout development, there has been research into this aspect of agile. The paper “Requirement Gathering and Tracking Process for Distributed Agile based Development” by Rehan Akbar, Muhammad Haris and Majid Naeem, explored the ideas of agile’s ability to allow changeable tasks design in large agile development groups, when agile uses simple documentation. The papers finding on the agile development documentation, was that simple design allowed teams to quickly shift design goals. The shifting in-goal allowed the management team, they were following, to better direct the other teams to finish the project(pp. 432-434). The shifting in the agile can be the reassessment of task that a team thought was “done”. Moving a task from “done” to working goes back to Knibergs image, letting us know that having something be strict like a “done” task be able to become a “to-do” task breaks from development methods like waterfall. There is also a downside to the reevaluation of “done” tasks that everyone should know about. Moving task from a “done” state to a “being worked” on state can make a project drag on which no teams wants. A team when deciding on bring back a done task might want to thing about the current task list and re plan when to rework a “done” task.
Akbar, R., Haris, M., & Naeem, M. (2008). Requirement Gathering and Tracking Process for Distributed Agile based Development. 8th WSEAS International Conference on APPLIED INFORMATICS AND COMMUNICATIONS, 429-436. Retrieved October 12, 2014, from http://www.wseas.us/e-library/conferences/2008/rhodes/aic/aic69.pdf
Ambler, S., & Holitza, M. (2012). Choosing an Agile Approach. In Agile for Dummies (IBM ed., p. 74). Hoboken: John Wiley & Sons.
Kniberg, H. (2014) What is Scrum? [Diagram] Retrieved October 12, 2014 from http://blog.crisp.se/2014/10/08/henrikkniberg/what-is-scrum