Often times, people in general find it difficult to start doing something. It’s not that the work itself is hard, but it appears that the law of inertia isn’t restricted to just physical objects. It’s hard for people to get started on their homework until the day before it’s due –I am a victim of that myself– but once I get started, I work until it is finished. What people need is a driving mechanism to transition from leisure to busy work. The backlog for instance is a driving force to start the development of software. It defines the starting point by organizing what needs to be done in what order. In the sample picture shown below, the work is strategically divided among a number of days with different objectives in mind.
A backlog is a point of reference that Agile users formulated as part of their project. They first create user stories, which are hypothetical customer reviews, in order to develop the goals the end-product is expected to have. These reviews put utility into perspective for the Agile team so they know whether or not the thing they are creating will become useful. As part of Agile methodology, these goals are expected to either be reiterated or changed during the biweekly meetings. If the product’s goal is something people envision to be both achievable and useful, then it should be kept. If not, then it either needs to be revised until it fulfills the aforementioned conditions, or needs to be tossed out completely.
Also, a backlog can be used to setting milestones for the upcoming tasks. The Agile team can divide the work by using the user stories as checkpoints. To some degree, it is a way for the team to monitor their progress and ensure that their pace is acceptable. Multiple user stories can be completed at the same time because they can be similar enough so that one code can address both needs.
As the product nears completion, the backlog is then used as reference for debugging. Suppose the product created is a website. The process will involve the debugger running tests by navigating through the interfaces of the website to make sure it works correctly. This involves spotting graphical glitches (missing user interfaces, awkward formatting, etc), updating dead links, and monitoring the speed of the servers that the site is hosted on (a.k.a. stress tests).
Adams, Scott. (2011). Dilbert.
Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … & Thomas, D. (2001). Manifesto for agile software development.
Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.
Retrieved from: http://bit.ly/1r7UBnD
Topics in Scrum. (2014).
Retrieved from: http://www.mountaingoatsoftware.com/agile/scrum/sprint-backlog