Search

Importance of Sprint Retrospective In Agile Project Management

There is a buzz in the community of IT service providers and software developers about the terms like Agile software development, Agile project management, Agile transformation, Agile methodology, Agile adoption etc. After coming across encouraging Agile journey experiences within the industry, a number of software development companies are switching over to an Agile culture. Once the Agile teams achieve efficiency, the team members start missing some important steps well defined in Agile project management; one of those is ‘sprint retrospective’ – a very important Agile activity to improve the process, quality, client’s side satisfaction and profitability.  What is Sprint Retrospective? During the sprint retrospective, the entire team inspects the iteration and decides what can be done to improve the process. The outcomes of retrospective meetings are communicated to all the members; and, the suggestions are incorporated in the next iteration. It makes the retrospectives a never-to-miss exercise for short-cycled improvement and modification to varied circumstances. Here, I would refer “Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises” written by Luis Gonçalves and Ben Linders. The ideal way to get the most of retrospective is to use the user stories describing ‘who, what & why’ for planning and tracking the improvements. 7 Key Benefits of Sprint Retrospectives:  It helps the support team to identify and resolve the conflict areas.  It helps the Agile team to improve the processes continuously by knowing ‘what can be improved’.  It allows all the members to share their views for improvement with the feel of ownership. It provides the roadmap for ‘start, stop doing & continue’.  It helps the project managers to keep the project on the right track by fixing the priorities and directions. It helps to identify the risk and problem factors at an early stage. It creates transparency and builds trust among the team members that strengthen the team spirit.  5 Stages of Sprint Retrospective That Make it Important:  Setting the environment and the stage to make the team members prepared for Agile retrospective is the first step.  The 2nd stage is to gather and analyze the data of previous projects to have insights in to previous actions. It helps to fix the quality benchmarks for specific tasks. The collected insights including facts & feelings are shared to help the team members address all the relevant issues in particular sprint retrospective as well as to find the most secure and effective way to proceed further.   The tasks are assigned with fixed responsibility to avoid any misunderstanding among the team members.   Each sprint retrospective ends with the acknowledgement and appreciation to contribution of each member.      The Five Agile - Sprint Retrospective Techniques to Deliver Better: 1. 4 Ls sprint Retrospective Technique:  The 4 Ls is a widely used data collecting technique for sprint retrospective involving the individuals to express their opinions independently on Post-Its or in group discussions.  The 4 Ls stand for:  Liked – Things you like Learned – Things you learn Lacked – Things that could be improved Longed for – Things you wish for 2. Speedboat Sprint Retrospective Technique:  The speedboat retrospective technique was first presented by Luke Hohmann in his book “Innovation Games”.  The project manager draws a speedboat on a chart representing the Agile team. The team members put their ideas on the Post-Its; which are connected with speedboat like anchors. The intention is to find out the hurdles refraining the team members to move fast to deliver at the time. Now, the solution-focused approach turns each anchor into the gust of wind; and, the team starts delivering as it should. 3. Speed Car Sprint Retrospective Technique: It is the simplest retrospective technique to identify the hurdles and supporting powers both.  The participants are asked to create post-its and place them over the ‘Engine’ and ‘Parachute’ of a speed car drawn on a chart. The post-its placed on the engine show the things that helped to perform and deliver; while, the post-its placed on the parachute show the things that slowed down the progress. The meeting ends with finding the solutions to each hurdle with the intention to apply the supporting forces in more areas.  4. Mad, Sad & Glad Sprint Retrospective Technique:  The participants are asked to create post-its in three different colors. The idea behind the exercise is to identify the things that made the participants feel mad, sad & glad during the sprint. The post-its under ‘Mad’ highlight the problems, time-wasting exercises, unexpected results/developments etc. The post-its under ‘Sad’ highlight the issues within the team that slowed down the progress. The post-its under ‘Glad’ highlight the issues like successes, learning, and achievements. The discussion helps the team leader to find out the viable solution to each highlighted issue. 5. KALM Sprint Retrospective Technique: The KALM stands for-  Keep - Something valuable you would love to repeat  Add- A new concept you would love to try. Less - Something being done already, and; you would like to do it less. More- Something being done already; and, you would like to give it more value.   The KALM retrospective technique stimulates the conversions over ongoing activities and perceived values.   Ensure the team follows up on retrospective actions or there’s no point capturing them in the first place #scrum #retrospective — John Leighton (@johnjleighton) May 8, 2018   Summary:  On being asked about the sprint meetings, the majority of Scrum Masters say that they simply ask- ‘What went well? ‘What didn’t work well?’ and ‘What can be improved?’.  The importance of sprint retrospective in Agile –Scrum project management lies in learning because it leads the team members towards- ‘what did we learn?’ The continuous monitoring for improvement is the fundamental of Agile project management; and, the sprint retrospective brightens the success prospects.
Rated 4.0/5 based on 42 customer reviews

Importance of Sprint Retrospective In Agile Project Management

255
Importance of Sprint Retrospective In Agile Project Management

There is a buzz in the community of IT service providers and software developers about the terms like Agile software development, Agile project management, Agile transformation, Agile methodology, Agile adoption etc. After coming across encouraging Agile journey experiences within the industry, a number of software development companies are switching over to an Agile culture. Once the Agile teams achieve efficiency, the team members start missing some important steps well defined in Agile project management; one of those is ‘sprint retrospective’ – a very important Agile activity to improve the process, quality, client’s side satisfaction and profitability. 

What is Sprint Retrospective?

During the sprint retrospective, the entire team inspects the iteration and decides what can be done to improve the process. The outcomes of retrospective meetings are communicated to all the members; and, the suggestions are incorporated in the next iteration. It makes the retrospectives a never-to-miss exercise for short-cycled improvement and modification to varied circumstances. Here, I would refer “Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises” written by Luis Gonçalves and Ben Linders. The ideal way to get the most of retrospective is to use the user stories describing ‘who, what & why’ for planning and tracking the improvements.

7 Key Benefits of Sprint Retrospectives: 

  1. It helps the support team to identify and resolve the conflict areas. 
  2. It helps the Agile team to improve the processes continuously by knowing ‘what can be improved’. 
  3. It allows all the members to share their views for improvement with the feel of ownership.
  4. It provides the roadmap for ‘start, stop doing & continue’. 
  5. It helps the project managers to keep the project on the right track by fixing the priorities and directions.
  6. It helps to identify the risk and problem factors at an early stage.
  7. It creates transparency and builds trust among the team members that strengthen the team spirit. 

5 Stages of Sprint Retrospective That Make it Important: 

Stages of sprint restrospectives

  1. Setting the environment and the stage to make the team members prepared for Agile retrospective is the first step. 
  2. The 2nd stage is to gather and analyze the data of previous projects to have insights in to previous actions. It helps to fix the quality benchmarks for specific tasks.
  3. The collected insights including facts & feelings are shared to help the team members address all the relevant issues in particular sprint retrospective as well as to find the most secure and effective way to proceed further.  
  4. The tasks are assigned with fixed responsibility to avoid any misunderstanding among the team members.  
  5. Each sprint retrospective ends with the acknowledgement and appreciation to contribution of each member.   
     

The Five Agile - Sprint Retrospective Techniques to Deliver Better:

1. 4 Ls sprint Retrospective Technique: 

The 4 Ls is a widely used data collecting technique for sprint retrospective involving the individuals to express their opinions independently on Post-Its or in group discussions.  The 4 Ls stand for: 

  • Liked – Things you like
  • Learned – Things you learn
  • Lacked – Things that could be improved
  • Longed for – Things you wish for

2. Speedboat Sprint Retrospective Technique: 

The speedboat retrospective technique was first presented by Luke Hohmann in his book “Innovation Games”.  The project manager draws a speedboat on a chart representing the Agile team. The team members put their ideas on the Post-Its; which are connected with speedboat like anchors. The intention is to find out the hurdles refraining the team members to move fast to deliver at the time. Now, the solution-focused approach turns each anchor into the gust of wind; and, the team starts delivering as it should.

Speedboat Sprint Retrospective Technique


3. Speed Car Sprint Retrospective Technique:

It is the simplest retrospective technique to identify the hurdles and supporting powers both.  The participants are asked to create post-its and place them over the ‘Engine’ and ‘Parachute’ of a speed car drawn on a chart. The post-its placed on the engine show the things that helped to perform and deliver; while, the post-its placed on the parachute show the things that slowed down the progress. The meeting ends with finding the solutions to each hurdle with the intention to apply the supporting forces in more areas. 

Speed Car Sprint Retrospective Technique

4. Mad, Sad & Glad Sprint Retrospective Technique: 

The participants are asked to create post-its in three different colors. The idea behind the exercise is to identify the things that made the participants feel mad, sad & glad during the sprint. The post-its under ‘Mad’ highlight the problems, time-wasting exercises, unexpected results/developments etc. The post-its under ‘Sad’ highlight the issues within the team that slowed down the progress. The post-its under ‘Glad’ highlight the issues like successes, learning, and achievements. The discussion helps the team leader to find out the viable solution to each highlighted issue.

5. KALM Sprint Retrospective Technique:

The KALM stands for- 

  • Keep - Something valuable you would love to repeat 
  • Add- A new concept you would love to try.
  • Less - Something being done already, and; you would like to do it less.
  • More- Something being done already; and, you would like to give it more value.  

The KALM retrospective technique stimulates the conversions over ongoing activities and perceived values.  

 

Summary: 

On being asked about the sprint meetings, the majority of Scrum Masters say that they simply ask- ‘What went well? ‘What didn’t work well?’ and ‘What can be improved?’.  The importance of sprint retrospective in Agile –Scrum project management lies in learning because it leads the team members towards- ‘what did we learn?’ The continuous monitoring for improvement is the fundamental of Agile project management; and, the sprint retrospective brightens the success prospects.

Shubhranshu

Shubhranshu Agarwal

Blog Author

Shubhranshu Agarwal is a technical writer with special interest in business management and project management subjects. Over the 15 years of freelance content writing, he has written a lot to help the industries, businesses and project managers to achieve the sustainable growth by implementing strategic critical management methodologies.
 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story.     This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story?   User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.  User stories typically follow a simple template as below. As a , I must be able to so that I can .  User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.  Writing user stories on an index card is actually the ‘Card’ part of the 3 C’s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type ‘Story’ as shown below.  The user story in the format listed above can be written in the summary field of the new issue creation screen.  User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn’t a test for it yet)   Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL — Visure Solutions (@VisureSolutions) 21 November 2017   JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words ‘Epic’ and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C’s in user stories that is ‘Confirmation’ is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria.   Gearset’s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets & keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm — Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the ‘Conversation’ component of user stories which is the 3rd C in the 3C’s.  Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner.    
Rated 4.0/5 based on 1 customer reviews
Writing Effective User Stories in JIRA

User stories are one of the main methods of commun... Read More

Scrum Master vs. Project Manager: Differences and Similarities

Organizations that are new to Agile and Scrum commit some deadly blunders. The most common and overlooked one is the lack of clarity of the roles of the Scrum Master and the Project Manager. This is more often seen in smaller Scrum teams, where these two discrete roles overlap.  There are of course similarities between Scrum Master and Project Manager roles. But that does not give way to ignoring the distinct differences between an Agile Project Manager and Scrum Master.  We have spaced out this article into various sections-    Scrum Master vs. Project Manager roles and responsibilities Scrum Master roles and responsibilities: Scrum Master is referred as a facilitator, who manages the teams that are implementing the Agile methodology. Scrum framework is the best framework for smaller teams of developers, who can break their work into a Sprint in order to get your project done at the end of every sprint.  The roles and responsibilities of the Scrum Master includes- Sprint planning  Scheduling the daily Scrum meeting Managing Scrum process responsibly Helping the Scrum teams to follow Scrum practices Removing barriers so the team can focus on their work Assisting with the Product Backlog Co-operating with Product Owner in designing Product Backlog items for the next Sprint Protecting the team from external distractions Recording and assisting to improve team dynamics   *Project Manager roles and responsibilities: Project manager’s role is to manage the projects and ensure that the project meets the requirements. The roles and responsibilities of the Project Manager are as follows- Defining project scope to the team Planning project target Preparing the work schedule for the team members Gathering requirements Defining the resource requirements for the project Preparing the budget for a project Assuring quality Mitigating the risks Monitoring the plans Getting user feedback Managing relationships with the client and the stakeholders Ending the project   Similarities between the Scrum Master and the Project Manager Project Manager and Scrum Master both are humans and they both make mistakes. But they both debug and learn from the mistakes. They both can communicate, receive feedback, mitigate the risks, and enable a great bonding within a team. Actually, neither the Project Manager nor the Scrum Master is the supreme authority. The Project Manager has to report to the client and the stakeholders, whereas the Scrum Master has to report to the Product Owner alongside the stakeholders and clients. Both Project Manager and the Scrum Master fail when they ignore the basic principles that are supposed to be adhered to. They fail when they not only neglect being professionals, but also when they are any less than skilled professionals. Sometimes, they may also fail when they disrespect the team members’ opinions. Differences between the Agile Project manager and Scrum Master While noting down the differences between the Project Manager and the Scrum Master, you will find out that the Project Manager plays the leadership role by leading a planning for the execution of the project. Scrum Master plays a support role for the team members, by working closely with the team and assuring that they are following Agile principles properly. Let’s look at the major differences between the PM and SM: Project Manager(PM) vs.Scrum Master(SM) Goals Has defined goals like- Completing the project on time, planned budget, and scope Makes sure that the team members are well trained to follow Agile practices appropriately. Also, SM coaches the Scrum teams and mentions the timeline to finish the project. Quality Assurance PM also knows the importance of quality, but doesn’t know how to achieve this. Usually, a consultant is hired to fix the errors. SM assures the quality and very well knows the importance of it. Team Size Project Managers like to make the things large. PM works with more people and a huge budget. In this way, they improve to Program Manager Scrum Master always tries to keep things smaller. They like to work in small teams irrespective of budget. Average Salary Rs.1,351,403 per year Rs 1,036,017 per year Job Description The job description of the Project Manager includes- Planning, creating budget and the related documents PM has to work with upper management to ensure a scope and direction of a project PM has to work with another department also, in case of emergency sometimes have to work themselves or instruct the team to finish a goal. The job description for Scrum Master includes- Resolves barriers and controls the Scrum processes. Making a team aware of Agile and Scrum to deliver successfully Facilitates the Scrum ceremonies Ensures that a project is running smoothly with the help of the tools Executes the Product Backlog as per the Product Owner prioritization Solves team conflicts with good communication skills Motivates the team Monitors the Scrum processes to increase efficiency   Scrum Master vs. Project Manager certification The Scrum Master and the Project Manager certifications are the two most popular certifications of the Agile and Waterfall methodologies.  Scrum.org report as of 30th April 2017 states that around 110,000+ people are  Scrum certified. Only 56% of the Project Management Specialists are holding a Project Manager Certificate, even in Big IT companies. This was revealed in a survey conducted by IBM.    Last words: Deciding between the Scrum Master and Project Manager certification is indeed a tough choice and entails a careful consideration of the prospects of each. Eventually, the role of a Scrum Master is proved as a ‘deciding factor’ of the successful projects. The Scrum Master and the Project Manager both have distinct roles. Both need particular skill-sets and a right person to make the work happen.       
Rated 4.0/5 based on 9 customer reviews
1601
Scrum Master vs. Project Manager: Differences and ...

Organizations that are new to Agile and Scrum comm... Read More

Value Proposition of Agile Development

Value Proposition of Agile Development The benefits of Agile development have been extolled extensively across the web and almost every one of us is well aware of those benefits. Some of the inquisitive members have taken the efforts to research and study the Agile development framework to understand why those benefits are the products of this framework under discussion. I have no intention of going in that direction since it requires a detailed discussion that is possible in a classroom setting [reach out to your KnowledgeHut support to ask for one].   Through this article, I want to discuss the value propositions of Agile development with you i.e. in essence means, how the benefits of Agile play out for you on the ground during the execution time. What are those actual in-hand benefits that you and your team will reap because of the good thing in Agile development called Value proposition? That is what I want to share with you.   Visibility: The first value proposition that we are going to discuss is “Visibility”. The visibility to the product owner, project sponsors, managers, and engineering team about the current state of the project or product development and whether  we are headed in the right direction or not. Unlike waterfall model, where visibility is highest during requirement gathering phase then suddenly everything goes black and behind curtains with no idea about building the right thing, then suddenly we ship the product with the highest visibility. Alas, that is too late to correct anything if things have gone in the wrong direction. The value brought by Agile in this matter is that visibility remains high at all times; it slightly dips for a week or two during actual development, but it again picks up; so on an average, it remains consistent and at a higher level than waterfall model. This can be easily understood through the means of this graph where the dotted line shows how visibility into the project direction suddenly dips during the execution phase, but it remains constant for Agile.   Adaptability: The word adaptability refers to the ability to accept changes or changing business scenarios and move forward in the new direction with the same vigor and enthusiasm. In any project, adaptability is highest since the project is being kicked off, requirements are being collected so any direction, request or change can be easily accommodated. But things start to change in a traditional waterfall model soon enough and adaptability goes down considerably from the design stage and becomes lowest during shipping. Because once those things are finalized then there is no way to change them without starting all over again. Whereas in the Agile mode, though adaptability remains highest during the initial phase, it continues to hover around the same range through the project duration since every sprint is a chance to pick up something new or change direction as per business need. As you will see in the below diagram, adaptability looks  like this:   Business Value: How your project or product is delivered at the end or at regular intervals, and how it will help the business or your project owner is considered as business value. Because business does not get any value from your project until you deliver something that can be used by end consumers. Needless to say, business value is always available to be consumed at the end of project cycle or rather we should at the time of shipping. The shipping can be at regular intervals [as in the case of Agile] or in the end [as in case of traditional development methods]. In this sense, both Agile and Waterfall sound similar to us but in reality, they are not. Because they vary in the way of delivering business value. Since waterfall believes in shipping in the end or when the product is completely ready, so business value shoots up from 0 to highest suddenly towards the end. That part is obvious. Let us see how it evolves for Agile methodology. Here in Agile, we start delivering incremental versions of the product from the first sprint; so Business value starts getting generated from Sprint 1 and continues to go up until the last sprint or the time when product owner asks us to stop. This is clearly reflected in the graph shown below. Risk This is a remarkably interesting aspect of value proposition for any development model. We all want to avoid risks somehow; sometimes we succeed and sometimes we fail miserably, and our worst nightmares come true at those times. It is not my intention or objective here to dive into many ways to cut risks, but instead, analyze the concept of risk and how it varies according to the development model being followed by the team. It is a common sense that risk is highest in the initial phase of the project since we are dealing with the utmost unknown at that time. Any wrong action or decision by us will lead to failure and a complete wastage of resources. As we progress and start building something, the risk continues to go down and becomes 0 when we ship it. Because either we have succeeded by then or we have failed utterly. Agile allows us to cut down risks faster than the traditional methods because the visibility is maintained at a high level throughout, so if something is going wrong then it is addressed immediately, owing to high adaptability. If we pause and analyze for a while, we understand that high visibility, high adaptability and ability to deliver from early in the game allows us to have minimal risk score through the project rather than working hard for 1 year then finding out that you built something that was not required in first place. That is how Agile development helps us manage risks effectively as long as we execute Agile properly. Conclusion So, as we saw here, any development methodology, related to software field or manufacturing or service-based industry can be analyzed over 4 value proposition parameters, namely: Visibility, Adaptability, Business Value and Risk. In the above post, through means of graphical analysis, we compared Agile development methodology Versus Traditional waterfall and found that Agile development is much better to be followed in recent times with a condition that it has to be executed correctly. You can read my other blog post about “10 deadly myths of Agile and Scrum” whereby I have explained how wrong implementation of Agile and Scrum harms us more than benefit us. With this thought in mind, I take your leave and I hope that next time when you explain to your stakeholders about the need to use Agile, you have a better and stronger story to tell. All the best!
Rated 4.0/5 based on 20 customer reviews
Value Proposition of Agile Development

Value Proposition of Agile Development The be... Read More

other Blogs