“Agile itself is just a newer, best-of-breed collection of methodologies used to develop and maintain software” (Ambler & Holitza, 2012). Behind all of the great processes within the agile framework, none of it is possible without the people to organize it and execute it. The agile team consists of six primary roles and five secondary roles. Similar to other methodologies, agile allows one person to hold one or more roles. For example, a person can be in the role of the team member while also filing the role of the team leader. We will cover the primary roles, what the agile team is, what the backlog is, what they are for and how they are important.
The first role is the most important, the stakeholder. Without them, there is no agile team because the stakeholder is the one requesting the work to be done in the first place. They are normally not just an end-user; they may also be the one with the money. The second role is the product owner. The product owner is the liaison between the agile team members and the stakeholder. The product owner is what is known as the “one voice of the customer” (Ambler & Holitza, 2012). The product owner is also responsible for sustaining and ranking items in the backlog which will be discussed later. The third role is the regular team member. The team member is the one doing the work. The role of the team member can refer to anyone from the people writing the code to the people running the tests.
Furthermore, the fourth role is the team leader. In addition to wearing their programming hat, one of the team members also has to lead the team to successful completion. The team leader is mainly there to keep everyone focused and on task. For example, to help the team stay focused the team leader will resolve issues before the issues jeopardize the sprint deliverables in order to let the team members continue working towards their goal for the day. The fifth role to mention is the architecture owner. The architecture owner is someone who owns the architecture of the solution. In a small team you could have multiple architecture owners or have everyone fill the role. On the other hand, having many architecture owners within a large team would be problematic. It is often difficult to make design decisions by committee. Instead, in a large team, there should only be or a select few satisfying the role of the architecture owner. The last and final role to mention is the agile mentor. The agile mentor is not necessarily part of the agile team but they are influential. The agile mentor is basically a coach and nothing more. They are usually well versed in the techniques of the agile framework and their whole purpose is to provide feedback and recommendations to make the teams more successful in their agile implementation.
So how does the agile team decide what gets worked on? That is where the concept of a backlog comes into play. The backlog is basically a list of requirements and there are m 
ultiple backlogs within one particular solution. They are referred to as the product backlog and a sprint backlog. Expanding on the role of the product owner, they are responsible for prioritizing and maintaining the backlogs. The product backlog contains the list of requirements for the entire product, hence the name product backlog. Moreover, the sprint backlog a subset of the requirements will be or were worked on during an iteration.
The backlogs are reviewed and/or modified during the iteration review or the release planning session. The iteration review takes place after every sprint where the team members showcase their accomplishments to the stakeholders and the product owner. In addition, if new items emerge from the iteration reviews, the product owner must take note of them so the new items can be brought to the release planning session. The release planning session consists of the same cast of characters minus the team members. The beauty of how the backlog gets maintained shows that there is no need to have a complete list of requirements on day one because this iterative process will force the backlog to become comprehensive over time. To compliment an efficient team structure would be a concise and visible backlog. It will promote innovative collaboration and integrate lessons learned from sprint to sprint. It will also allow the backlog to response to change. After every sprint all of the most important items get moved to the top, ensuring the customer is continually getting what they desire the most. “In practice, it’s not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five”(Software, 2014).
Click here to view the Criterion Report
References
Ambler, S. W., & Holitza, M. (2012). Agile For Dummies IBM Limited Edition. Hoboken: John Wiley & Sons, Inc.
Software, M. G. (2014, 7 13). Mountain Goat Software. Retrieved from Topics in Scrum: http://www.mountaingoatsoftware.com/agile/scrum/product-backlog
Product Backlog Image – http://www.informit.com/articles/article.aspx?p=2117898&seqNum=2
Users and Customers Image – http://www.romanpichler.com/blog/grooming-the-product-backlog
I really like your content and how you added examples to backup your statements. It was nice to know that you clearly addressed who was a part of the Agile team and what each team member task was. I also like how you transitioned from Agile team to what the Agile team does, which is working on the Product Backlog. Also, there was a small typo in the beginning of your fourth paragraph which can be easily corrected. Overall, the content was very clear.
I love how you organized and structure your blog. Its very methodical and it flows. In addition, I like how everything each point answers a rhetorical question and you use quotes from different text. I just felt like maybe you could organize the paragraphs where there a certain way to define them. Content-wise, I learned a lot about the backlog and agile team itself.