The Agile Team and what is a Backlog?

The Agile Team is a group of individuals that take part in the Agile software development process. The positions vary depending on which type of Agile methodology is being used, but I will describe some of the more common team positions. One of these necessary positions is the Product Owner. This individual is usually the manager of the requirements backlog(discussed later in this post). He or she is responsible for interpreting and delineating the product requirements in the backlog. The Product owner decides what needs to be done in each sprint, and instructs the teams. In Scrum, one of the more popular Agile methods,  there is the Scrum Master. This individual is the facilitator, he or she enforces what few rules there are in the Agile methodology , and works to keep the development process smooth and progressive. Then there are the team members, a group that consists of a variety of professionals that are necessary to the development process. These individuals are collocated, which means they are ideally working together with face-to-face contact. The developers, testers, and other team members collaborate during each sprint, instead of working in separate locations and never truly discussing the development process while it is happening. This is one of the important differences between traditional development methods and the Agile development methodology (Williams, 2012).

The backlog is one of the most important aspects of the Agile software development methodology. It is a list that contains all features and changes that need to be made to the product. The one characteristic that is shared among all the items is that they all need to add value for the customer.  These items can be user stories, or actual features that need to be coded. The list is written with the highest priority items on the top, and can be updated and modified throughout the development process.  Next to each item, is the estimate of how much time that item will take to complete.  The backlog can also contain tasks that are indirectly related to the product development but are still necessary. An example is the updating of software on the machines used to create the product. The product owner is responsible for grooming the backlog, so the team can always trust that the backlog contains simply what needs to be done. The product owner does this by changing the priority of the tasks, adding new tasks that are discovered, and even deleting tasks that are no longer deemed necessary (Meso et al., 2006).

Here is an illustration of Agile team roles compared to traditional team roles.


This is an example of a Scrum Product Backlog.


Works Cited:

Williams, L.(2012). What Agile Teams Think of Agile Principles. Communications of the ACM, 55(4), 71-76. doi:10.1145/2133806.2133823

Meso, P., & Jain, R. (2006). Agile Software Development: Adaptive Systems Principles and Best Practices. Information Systems Management, 23(3), 19-30

First Picture Link:

Second Picture Link:

What is Agile and what are user stories?

The Agile method for software development differs from traditional methods in that it provides an ability to reassess(and change if necessary) the direction of a project throughout the development process. This is done by breaking up the project development into short, repeated sessions called sprints. Many traditional methods assume that all is known beforehand about what needs to be done in the project, and this assumption causes issues when problems are discovered during the process. The Agile methodology for software development provides for issues that can arise in the process of working toward an end result that might not be completely understood by team. Agile accounts for the learning curve associated with such projects, because it is not uncommon for a development team to learn better ways to implement the solution along the way. Agile is a stark contrast to the Waterfall development methodology. This is an approach that relies heavily on specified requirements and product design done entirely in advance. Waterfall development methods can make changing previously completed aspects of software difficult, as those changes can necessitate changes in other parts of the software, all of which has already been designed and specified thoroughly. These drawbacks are described by Lehman and Sharma (2011), ”We have used the Waterfall, or plan-based, method many times for past projects, and we have consistently paid a significant price for the “Big Design Up Front” problems that go with that type of schedule” (p.749). Agile allows the developers to create functional prototypes along the way. These prototypes are able to model some functionality of the desired end-product, and enable the developers and potential end users alike to test and even change aspects of the software.


Agile primarily uses user stories, instead of all encompassing specifications. A user story describes a requirement of the software, in narrative form. The user story explains the exact steps a user would take to achieve the desired result from the software. What appears to be one of the most useful aspects of a user story, is the fact that a single user story can showcase a very wide variety of requirements (Layman et al., 2006).


I believe that the Agile methodology could be used for many different types of projects. This is because the idea of revisiting all the parts of a product, and the ability to change direction at any point during development, seem to be things that any project development team would find beneficial, regardless of the type of project.

Works Cited:

Lehman, T.J. & Sharma, A. (2011). Software Development as a Service: Agile Experiences
SRII Global Conference (SRII), 2011 Annual , 749 – 758

Layman, L., Williams, L., & Cunningham, L. (2006). Motivations and measurements in an agile case study. Journal Of Systems Architecture, 52(11), 654-667. doi:10.1016/j.sysarc.2006.06.009

First Picture source:

Second Picture Source”