The Agile Team and What is a Backlog?

images

         How an Agile Team is structured is an important question that needs to be addressed in order to start a project using Agile. Under the Agile framework are various methodologies such as Scrum, Extreme Programming (XP), Crystal, Lean and Kanban. All of these approaches follow a basic structure consisting of a core team and the extended team. The extended team consists of the owner, key stakeholders, manager, and sponsors while the core team consists of the architect, developer, technical lead, iteration manager, and analysts. For smaller groups, multiple roles can be played by each member and depending on the project, only certain roles are necessary.

big-picture-1-agile-teams

       Source: http://bit.ly/1rrcEHm

        The Agile team is interchangeably called a Scrum team since Scrum is the simplest compared to the others and is used by a wide range of companies. For this reason, I will focus more on the Scrum organization structure. The Scrum team is cross-functional, meaning that each member has different expertise. It composes of a Scrum Master, the Product Owner, and members who develop, test, and finalize the project. The Scrum Master coaches the crew as they use Scrum; he or she gives honest feedback and motivates them to work at their highest level. The Scrum Master facilitates interactions among the team but each member manages themselves. As mentioned in an article by Hoda, Noble, & Marshall (2012), self-organizing teams are informal and team members choose their own affairs and play roles that pertain to the task (p.426).  The Product Owner provides the functionality requests to choose from and these are managed through backlogs.

Backlog and Its Importance

         A product backlog and a sprint backlog are two of the major components that make Agile effective. A product backlog is a list of requirements created and arranged by the Product Owner based on its level of importance. The product backlog is improved by additions of new features and removal of unwanted aspects over the duration of the project. Since the product backlog provides the team an understanding of the project envisioned by the Product Owner and for what reason it was chosen, members are able to set their goals towards a satisfying outcome. On the other hand, the sprint backlog is the list of the tasks needed to meet the requirements with an estimated completion date. The team plans and decides which product backlog items to put on each given iterations or sprint and individually commits to certain tasks. A case study by Paasivaara and Lassenius (2012) explains that there is typically a daily meeting in which the product backlog and the sprint backlog are discussed to finalize some work items, examine any unexpected occurrence and other issues relating to the project (p.408). The main purpose of a sprint backlog is to track the progress of the project development and the status of the tasks, exposing which areas need changes and which ones can be further improved. 

——————————————————————————————————————————–

References

Hoda, R., Noble, J., & Marshall, S. (2012). Self-organizing roles on agile software development teams. IEEE Transactions on Software Engineering, 39(3), 422-444. (2012, May 8). Retrieved September 20, 2014, from IEEE Xplore Digital Library.

Paasivaara, M., & Lassenius, C. (2012). Agile coaching for global software development.Journal of Software: Evolution and Process, 26(4), 404-18.

Advertisements

What is Agile and What are User Stories?

images (1)

A development methodology is an essential part of software development that plays a vital role in the project’s success. Throughout time, several methodologies have emerged in the marketplace. The Agile development methodology is a newer approach that rose to popularity due to its flexibility and ease of use compared to the older methodologies.  To better understand why agile is a more effective approach, a brief description of three other methodologies – Code-and-Fix, Waterfall, and Spiral model – will be provided.

The Code-and-Fix model is the oldest methodology in the history of software production. In this model, coding is done immediately and testing is performed later in the development cycle. This model does not need a design, but it’s hard to maintain. In the Waterfall model, initial requirements are needed. Unlike in the Code-and-Fix model, you can go back to a previous state to make changes, but it will be very difficult. If a client made changes to the initial requirement, the whole process will need to start all over again. In the Spiral model, risk maintenance is the main focus. Though this model makes adding functionality easier at a later time, it is a complicated approach that requires expertise in evaluating uncertainties that may arise during the development process.

Here’s a table I made to best compare  the methodologies:
agile

Now what’s so good about Agile?

Agile is somewhat a combination of the existing methods, which according to Abrahamsson and Conboy (2009), aid to extend its applicability to different projects (p.282). The Agile methodology requires the client’s active involvement as the project progresses. User stories are written to describe the client’s desired functionality. These user stories can be modified frequently to meet any changes. Additionally, team size and skills is not a concern since large teams are divided into sub-teams where each member is given specific responsibilities through a sprint backlog.  The sprint backlog is a list of specific work that needs to be completed in a given set of time. Depending on the decided time period, the team will meet and review which tasks are successfully completed. These sprints allow client’s feedback for the next sprint and coding bugs to be caught. So whether it’s a newly formed team or a group of specialist assigned to work on a project, agile will be appropriate to use. As mentioned by Cao and Chow (2007), team environment, customer involvement, and project management process are three factors that contribute to Agile’s success (p.967). We can clearly conclude that agile is suitable for any project with frequently changing standards. A great example is a software project that needs to constantly keep up with the trend. Using Agile, the product will be always up to date with the latest improvements.

——————————————————————————————————————-

References

Abrahamsson, P., Conboy, K., & Wang, X. (2009). ‘Lots done, more to do’: The current state of agile systems development research. European Journal of Information Systems, 281-287.
Cao, D., & Chow, T. (2007). A survey study of critical success factors in agile software projects. The Journal of Systems and Software, 81, 961-971.