What is an Agile Sprint Retrospective ?

At the end of the sprint review, before planning the next sprint, the team meets to review its own processes and methods. The Sprint Retrospective is inward looking (Martin, 2014). The Sprint Retrospective is time-boxed to 3-hours. The Scrum Team, the Scrum Master and optionally the Product Owner attends the meeting. The Sprint Retrospective is intended to answer two fundamental questions:

  • What we should continue to do
  • What we should stop doing
Sprint retrospective

Figure 1.1 : Sprint Retrospective. Martin, 2014. Retrieved from http://bit.ly/1v2LVh4

Managers and observers may not attend. It is reflective, looks inward and is intended to be honest so that process improvements result(Martin, 2014).The meeting is usually facilitated by the Scrum Master who will also take notes. The meeting must end with a list of action items that have been agreed upon and that will be implemented. Those changes may be added to the Product Backlog. (Babinet &  Ramanathan, 2008).

The Sprint Retrospective meeting has following key practices(Google sites(2012)) :

Key Practices

  • Meeting Customer satisfaction: The Sprint Retrospective can be used to reflect on how well the Scrum Team is addressing the customer satisfaction
  • Understanding Changing requirements: The Sprint Retrospective is a good place to assess if the Product Backlog is evolving and therefore the Scrum Team and Product Owner are flexible enough
  • Delivering working software regularly: The result and feedback received during the Sprint Review can be analyzed during the Sprint Retrospective to assess this element. The problems associated with the element can be resolved at this point.(Ambler & Holitza (2012))
  • Working with each other: Business and technical people should work together in order to achieve great results. Reflection on how well the business and technical people are working together is a good activity to ensure that the environment fosters communication between those two groups
  • Giving support and trust: Scrum Team can self-assess and also assess if management has provided an appropriate infrastructure
  • Involving in face-to-face conversation: The quality and frequency of the face-to-face conversation is a point that can be analyzed during a Sprint Review 
  • Delivering working software: Assessing the quality of the key deliverable to date is of essential value
  • Having a sustainable structure: Signs that could conclude that the project is not sustainable must be discussed
  • Technical excellence:  Quality is a non-negotiable aspect of Scrum and should be reviewed during the Sprint Retrospective
 Figure 1.2 : Sample Retrospective

Figure 1.2 : Sample Retrospective . Retrieved from http://bit.ly/1rKzVlN

  • Keeping the system simple: Signs of an unnecessary complex system should be discussed. Efforts should be made to keep things as simple as possible
  • Working in self-organizing team: Scrum Team should be self-managed. Any evidences that Scrum Team is hindered because not self-managed should be analyzed
  • Regular reflection: The Scrum Retrospective is a regular reflection activity. Hence, this will always be true.Google sites(2012)

References

 Martin (2014)(White Paper). A Quick Primer on Agility and Scrum. Retrieved from http://bit.ly/1v2LVh4

Babinet &  Ramanathan(2008). Dependency Management in Large Agile Environment. Retrieved from http://bit.ly/1rKzVlN

Ambler & Holitza (2012). Agile For Dummies®, IBM Limited Edition.  Hoboken, NJ : John Wiley & Sons, Inc.

Google sites(2012). Scrum Project Management. Retrieved from http://bit.ly/1CxtvyY

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

The Agile Team

Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. The Agile Team consists of roles such as Stakeholder, Product Owner and Team Member. (Ambler & Holitza, 2012)

Product Backlog

Figure 1.1 : Product Backlog. Pichler (2013). Retrieved from http://bit.ly/1vHAD5G

stakeholder is someone who’s financially impacted by the outcome of the solution and is clearly more than an end-user. A stakeholder may be one of the following: a direct or indirect user, a manager of users, a senior manager, an operations or IT staff member, The “gold owner” who funds the project, an auditor(s), a program/portfolio manager.  A product owner is the team member who facilitates the team members to understand the requirements of stakeholder. Along with this, a product owner represents the needs and desires of the stakeholder community to the agile delivery team. He clarifies any details regarding the solution and is also responsible for maintaining a prioritized list of
work items that the team will implement to deliver the solution (Ambler & Holitza, 2012). The role of a team member focuses on producing the actual solution for stakeholders. Team members perform testing, analysis, architecture, design, programming, planning, estimation, and many more activities as appropriate throughout the project. In addition to these roles, some team members also carry out very specific roles such as a team lead, an architecture owner and an agile mentor. A project might have need to add some or all following roles: Domain expert, Specialist, Technical expert, Independent tester, and Integrator. Success of the Agile team depends on how well the people with different roles communicate with each other.(Ambler & Holitza, 2012)

My Personal Experience with Agile Team and Backlogs

In our cloud computing project we are a team of three members and we are developing a cloud based application. We are using Agile methodology to keep track of the tasks. As Agile team has very specific roles assigned to each of the team members, we are using the same strategy. Based on the skills of the people, we assigned roles as domain expert, developer and tester. The backlogs are helping us to keep our project on track.Understanding and implementing the agile team concept and backlogs are helping me to execute my projects successfully.

What is a Product Backlog? : Purpose and Importance

Backlog_with_stories

Figure 1.2 : Product Backlog . Bozzuto (2014). Retrieved from http://bit.ly/12dktHf

A product backlog is nothing but a picture of how the final product should look like (Bozzuto, 2014). It consists of user stories arranged according to their priorities. After each iteration of agile cycle, the product owner updates the product backlog. The product owner needs to add any new user stories to the product backlog and rank those stories by priority. The product owner also adds stories that were scheduled for the current iteration, but not completed, back into the product backlog, and ranks those stories again based on the most recent priorities. The product owner needs to complete updates to the product backlog in time for the next iteration planning meeting.A good product backlog does not automatically ensure good software. However, the lack of a good product backlog often results in incomplete software that does not meet the requirements of your customers and stakeholders. Microsoft (2013)

Managing the product backlog is a full-time job. Simple techniques can help change what can be an overwhelming, time-consuming process to an interactive, iterative process that effectively engages team members, customers, and stakeholders. It’s essential, therefore, to learn solid techniques to help you build, prioritize, and maintain your product backlog. Microsoft (2013)

Pichler (2013). Pichler Consulting : The Product Ownership Test. Retrieved from http://bit.ly/1vHAD5G

Bozzuto (2014). The Product Backlog : An Agile WBS. Retrieved from http://bit.ly/12dktHf

Microsoft (2013). Microsoft Developer Network. Retrieved from http://bit.ly/11I3uMp

Ambler & Holitza (2012). Agile For Dummies®, IBM Limited Edition.  Hoboken, NJ : John Wiley & Sons, Inc.

What is Agile and What are User stories?

Let’s try to understand about Agile Development Methodology and User Stories. In general, a development methodology is nothing but the process followed to develop a software in a step-by-step manner. Agile itself is just a newer, best-of-breed collection of methodologies used to develop and maintain software. The Agile movement proposes alternatives to traditional project management. Agile approaches are typically used in software development to help businesses respond to unpredictability. Figure 1.1 explains the typical life cycle of Agile Development Methodology.

481x319xagile_methodology_overview.png.pagespeed.ic.hnSv2PKjMj

Figure 1.1 : Agile Development Model. Agile Methodology Blog(2011). Retrieved from http://bit.ly/1gGB5dE

To understand the differences between traditional ‘Code and Fix’ or big-bang approach of software development and Agile Development let’s compare it with a traditional waterfall development method.(Ambler & Holitza, 2012)

Agile development provides opportunities to assess the direction throughout the development life-cycle(Ambler & Holitza, 2012). This is achieved through regular cadences of work, known as Sprints or iterations, at the end of which teams must present a potentially ready to release product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” The waterfall method assumes that every requirement can be identified before any design or coding occurs. Hence, in the waterfall model, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited. When a team stops and re-evaluates the direction of a project every two weeks, there’s time to steer it in another direction. This “inspect-and-adapt” approach to development greatly reduces development costs and time to market.(Ambler & Holitza, 2012)

Agile methodology can be applied to develop many kinds of systems, including web-based applications, mobile applications, business intelligence (BI) systems, life-critical systems, and embedded software (Wikipedia, 2014). Organizations, including financial companies, retailers, healthcare organizations, manufacturers, and government agencies have adopted agile approaches.(Smith, 2010)

My Experience with Agile and User Stories

I am working on a encryption project and the team I am working with uses Agile methodology, As I studied Agile as a part of my CS200W course, it helped me lot to execute Agile methodologies while working on a real time project. We converted the requirements from customer into user stories. User stories, as explained below, precisely state what the business needs to do. As the requirements are precisely defined, the overhead associated with rework for changed requirement substantially decreases. I have personally experience this while working on encryption project. Let me quote example user story. As a user of encryption project

  • I want to store the information on my disk drive securely
  • I want the encryption to complete within maximum of 60 second window, irrespective of volume of data
  • I want to be able to encrypt the data on secondary disk and/or removable disk

What are User Stories?

A User Story is nothing but one or more sentences in everyday or business language, which will define what a user does or needs to do as part of his or her job function.User stories are used with Agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate the management of requirements. It captures the ‘who’, ‘what’ and ‘why’ of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small piece of paper. Here are some examples of User Stories. (Smith, 2010)

user_story

Figure 1.2 : User Stories (Smith, 2010). Retrieved from http://bit.ly/1pFNdmq

As a user of banking software I want to

  • Check my account balance
  • Transfer money across continents
  • Pay my telephone bills online

As a user of Vehicle Insurance software I want to

  • Check my insurance claim history
  • Add a driver to my insurance
  • Pay my insurance bills

As shown in figure 1.2, a user story is  used for planning and developing the software. Acceptance test is performed at each stage in development. Iteration Planning can easily be done with the help of user stories.

References:

Agile Methodology Blog(2011). Agile Methodology. Retrieved from http://bit.ly/1gGB5dE

Wikipedia(2014). Agile Software Development. Retrieved from http://bit.ly/1eV8cZ5

Smith (2010). Garren Smith Blog. Retrieved from http://bit.ly/1pFNdmq

Ambler & Holitza (2012). Agile For Dummies®, IBM Limited Edition.  Hoboken, NJ : John Wiley & Sons, Inc.