The Agile Team and what is a Backlog? What are they for and why are they important?

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.

Retrieved from:

Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … & Thomas, D. (2001). Manifesto for agile software development.

Retrieved from:

Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.

Retrieved from:

Topics in Scrum. (2014).

Retrieved from:

One thought on “The Agile Team and what is a Backlog? What are they for and why are they important?

  1. Great job Brandon! You kept your explanation of the backlog very casual and included a few jokes in there, which makes the whole article easier to read (that second sentence is awesome). The use of a Dilbert comic for this blog seems like it would be unrelated, but you couldn’t have picked a more appropriate comic! I really liked how you included examples when some of the concepts were tough to understand (Ex: graphical glitches, stress tests). Overall, you provided many different uses for a backlog and made it easy to understand instead of using big, fancy words to get your point across which I liked.


Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s