Another task bites the dust

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.

Citations:

Agile Task Table [Image]. Retrieved October 12, 2014, from: http://bit.ly/1ttEIXM

Checklist [Image]. Retrieved October 12, 2014, from: http://bit.ly/1z76L2X

(Secondary)

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)

(Primary)

Waters, K. (2007, April 8). Agile Principle 7: Done Means DONE! Retrieved October 12, 2014, from

http://www.allaboutagile.com/agile-principle-7-done-means-done/

Advertisements

One thought on “Another task bites the dust

  1. The amount of content that is in this blog post about a basic idea of Agile is outstanding. Features such as task lists make “Done” a more complex step in a good way. The in depth analysis that goes with a product might be tough, but task lists using Agile methodology is an easy way to accomplish your goals. A programmer must be sure that all tasks are correctly completed before entering the next sprint. I also loved the reference to another one bites the dust gave me a huge smile on my face.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s