Search

What is Sprint Retrospective Meeting in Scrum?

Along with the sprint review meeting, the sprint retrospective meeting is held at the end of each Sprint. Here comes the picture of ‘Sprint Retrospective’. So, what is Sprint Retrospective? Let’s discuss this. According to the Scrum Guide, the sprint retrospective is an “opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” During the Sprint Retrospective, the Scrum Master ensures that the event takes place and the attendants understand its importance. Sprint Retrospective is the best opportunity for the Scrum Team to improve all team members to improve the work process, ways to increase product quality by improving or adapting the definition of “Done”. During the Sprint Retrospective, the team discusses: What went well in the Sprint? What went wrong in the Sprint? What We had Learn in the Sprint? What should we do differently in the next sprint? 1. What went well in the Sprint?The possible questions that can be asked, to understanding the reason behind a success in the iteration by asking ourselves what went well to acknowledge all the good things that have happened. What motivated us to do it? What did we do differently to make it a success? Which training, skill, or knowledge contributed to the difference? Which strong point in you makes it happen? Which strong points of your team that made it happen? What is the team member’s contribution that helped you accomplish it? How did we achieve it? 2. What went wrong in the Sprint?These are the questions that the team shouldn’t be asked to analyze the performance rather to gather information and find the way to identify solutions in the upcoming Sprint. How did it go wrong? What did you do that went wrong? How many are responsible for this to go wrong? Where you aware of doing that it will go wrong? Did you understand it wrong and hence implemented wrong? Did you understand right but still it went wrong? What did we do well? 3. What We had Learn in the Sprint?What is the learning from this Sprint? These questions are helpful to identify what went right, and what went wrong. It encourages us to look at what we’ve learned about the way we’re working. Some examples might be: How was this sprint executed? Where did it go wrong in this sprint? When did it go wrong? How did it go wrong? Which techniques were useful? Which techniques were not useful? What went in a smooth fashion during this sprint? What did not go smooth during this sprint? What learning during this Sprint can educate us for the upcoming Sprint? 4. What Should We Do Differently in the Next Sprint? This section basically focuses on identifying the possible corrective actions from the past success, failure, and learning. How can the strength of the individual be utilized to resolve the issue? What should be done often to prevent the issue from arising again? Which actions must be implemented immediately for which you have the bandwidth and capability? Identify the 1 thing to be changed and explain how you could change it? What strategies will work to complete the job? What actions can a team take? What will you do in the upcoming Sprint to complete this action? How will you do it to make it a success? When will you do it during the Sprint? Do you require help to complete this? What additional support do you require? How will you let me know that you completed it? What will you do next after accomplishing this during the Sprint? Why Should You Run A Sprint Retrospective? Here are a few of the many benefits of retrospectives: Sprint Retrospective helps the team members to share their valuable feedback. It allows the team to document wins and areas of opportunity. It helps in identifying actionable list of next steps and identifies who’s owning which item. It identifies small, incremental changes that can lead to larger waves of improvement. It allows teams to iterate on their process to amplify results. It allows opinions to be heard. It helps the team mature. It makes each sprint better than the last. Length of Sprint Retrospective Meeting The thumb rule for the length of a sprint retrospective meeting is that it usually takes no more than 45 minutes per week of sprint duration. The following table illustrates this rule:Total Sprint DurationSprint Retrospective Duration1 week45 minutes2 weeks90 minutes (1.5 hours)3 weeks135 minutes (2.25 hours)4 weeks180 minutes (3 hours)5 Steps for Conducting Sprint Retrospective MeetingYou can follow the below steps: Set the stage: Set the objectives clearly and give time to the team to move into the right direction Gather data: Gather data as much as possible Generate insight Why did things happen the way they did? Identify patterns; See the big picture Decide what to do: Pick a few issues to work on and create concrete action plans of how you’ll address them Close the retrospective – Clarify follow-up; Appreciations; Clear end; How could the retrospectives improve? To conclude: Sprint Retrospective is the right platform to the team to success and ponder upon. Team members can think on the improvements that can be included in the next Sprint. Sprint Retrospective support the team in sharing of their interests and views, moving the team towards end solution. So, Sprint Retrospective will be the right step or process for Agile team to deliver quality product or service.
Rated 4.5/5 based on 2 customer reviews

What is Sprint Retrospective Meeting in Scrum?

3K
What is Sprint Retrospective Meeting in Scrum?

Along with the sprint review meeting, the sprint retrospective meeting is held at the end of each Sprint. Here comes the picture of ‘Sprint Retrospective’. So, what is Sprint Retrospective? Let’s discuss this. 

According to the Scrum Guide, the sprint retrospective is an “opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” During the Sprint Retrospective, the Scrum Master ensures that the event takes place and the attendants understand its importance. Sprint Retrospective is the best opportunity for the Scrum Team to improve all team members to improve the work process, ways to increase product quality by improving or adapting the definition of “Done”. 

During the Sprint Retrospective, the team discusses: 

  • What went well in the Sprint? 
  • What went wrong in the Sprint? 
  • What We had Learn in the Sprint? 
  • What should we do differently in the next sprint? 

1. What went well in the Sprint?

The possible questions that can be asked, to understanding the reason behind a success in the iteration by asking ourselves what went well to acknowledge all the good things that have happened. 

  • What motivated us to do it? 
  • What did we do differently to make it a success? 
  • Which training, skill, or knowledge contributed to the difference? 
  • Which strong point in you makes it happen? 
  • Which strong points of your team that made it happen? 
  • What is the team member’s contribution that helped you accomplish it? 
  • How did we achieve it? 

2. What went wrong in the Sprint?

These are the questions that the team shouldn’t be asked to analyze the performance rather to gather information and find the way to identify solutions in the upcoming Sprint. 

  • How did it go wrong? 
  • What did you do that went wrong? 
  • How many are responsible for this to go wrong? 
  • Where you aware of doing that it will go wrong? 
  • Did you understand it wrong and hence implemented wrong? 
  • Did you understand right but still it went wrong? 
  • What did we do well? 

3. What We had Learn in the Sprint?

What is the learning from this Sprint? These questions are helpful to identify what went right, and what went wrong. It encourages us to look at what we’ve learned about the way we’re working. Some examples might be: 

  • How was this sprint executed? 
  • Where did it go wrong in this sprint? 
  • When did it go wrong? 
  • How did it go wrong? 
  • Which techniques were useful? 
  • Which techniques were not useful? 
  • What went in a smooth fashion during this sprint? 
  • What did not go smooth during this sprint? 
  • What learning during this Sprint can educate us for the upcoming Sprint? 

4. What Should We Do Differently in the Next Sprint? 

This section basically focuses on identifying the possible corrective actions from the past success, failure, and learning. 

  • How can the strength of the individual be utilized to resolve the issue? 
  • What should be done often to prevent the issue from arising again? 
  • Which actions must be implemented immediately for which you have the bandwidth and capability? 
  • Identify the 1 thing to be changed and explain how you could change it? 
  • What strategies will work to complete the job? 

What actions can a team take? 

  • What will you do in the upcoming Sprint to complete this action? 
  • How will you do it to make it a success? 
  • When will you do it during the Sprint? 
  • Do you require help to complete this? 
  • What additional support do you require? 
  • How will you let me know that you completed it? 
  • What will you do next after accomplishing this during the Sprint? 

Why Should You Run A Sprint Retrospective? 

Here are a few of the many benefits of retrospectives: 

  • Sprint Retrospective helps the team members to share their valuable feedback. 
  • It allows the team to document wins and areas of opportunity. 
  • It helps in identifying actionable list of next steps and identifies who’s owning which item. 
  • It identifies small, incremental changes that can lead to larger waves of improvement. 
  • It allows teams to iterate on their process to amplify results. 
  • It allows opinions to be heard. 
  • It helps the team mature. 
  • It makes each sprint better than the last. 

Length of Sprint Retrospective Meeting 

The thumb rule for the length of a sprint retrospective meeting is that it usually takes no more than 45 minutes per week of sprint duration. The following table illustrates this rule:

Total Sprint DurationSprint Retrospective Duration
1 week45 minutes
2 weeks90 minutes (1.5 hours)
3 weeks135 minutes (2.25 hours)
4 weeks180 minutes (3 hours)

5 Steps for Conducting Sprint Retrospective Meeting

You can follow the below steps: 

  1. Set the stage: Set the objectives clearly and give time to the team to move into the right direction 
  2. Gather data: Gather data as much as possible 
  3. Generate insight 
  4. Why did things happen the way they did? Identify patterns; See the big picture 
  5. Decide what to do: Pick a few issues to work on and create concrete action plans of how you’ll address them 
  6. Close the retrospective – Clarify follow-up; Appreciations; Clear end; How could the retrospectives improve? 

To conclude: 

Sprint Retrospective is the right platform to the team to success and ponder upon. Team members can think on the improvements that can be included in the next Sprint. Sprint Retrospective support the team in sharing of their interests and views, moving the team towards end solution. So, Sprint Retrospective will be the right step or process for Agile team to deliver quality product or service.

KnowledgeHut

KnowledgeHut

Author

KnowledgeHut is an outcome-focused global ed-tech company. We help organizations and professionals unlock excellence through skills development. We offer training solutions under the people and process, data science, full-stack development, cybersecurity, future technologies and digital transformation verticals.
Website : https://www.knowledgehut.com

Join the Discussion

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

Suggested Blogs

Advantages of Agile Testing Methodology

What is Agile Testing? As the name implies, agile course projects are executed very quickly and with flexibility. Agile methods involve tasks executed in short iterations or sprints.Agile Testing is also iterative and takes place after each sprint, rather than towards the end of the project. Testing courses iteratively helps to validate the client requirements and adapt to changing conditions in a better manner. As soon as the build is out, testing is expected to get started and  bugs if any should be reported at once. As a Tester, you must work with the team and share your thoughts on the client requirements at the beginning rather than towards the end of the project. Emphasis has to be laid down on the quality of the deliverable despite the short timeframe. This will further help in reducing the cost of development and your feedback will be implemented in the code which will avoid the defects coming from the end user. Advantages offered by Agile Methodology: The most significant advantage of Agile Methodology is the saving of time and money. There is less documentation required. Although documents help to a great deal in verifying and validating the requirements, considering the time frame of the project, this approach focuses more on the application rather than on documentation. Since it is iterative in its form, there is regular feedback from the end user so that any changes can be implemented as soon as possible. And because all phases of SDLC need to be completed very quickly, there is transparency with regard to the work done by each individual working on the project during each phase. Another advantage that Agile Methodology offers is that any changes or enhancements can be implemented without any budget constraint. These changes may necessitate some adjustment in the already allotted time frame which will not be difficult . Daily meetings and discussions on the Agile project  can help to determine any issues well in advance and work on addressing them. Quick coding and Testing makes the management aware of the gaps existing in the requirements or technology used, and they can try to find a workable solution for the same. Hence, with quicker development, testing and constant feedback from the user,  Agile methodology becomes the most appropriate approach for projects that are required to be delivered in a short span of time.
Rated 4.0/5 based on 20 customer reviews
Advantages of Agile Testing Methodology

What is Agile Testing? As the name implies, agi... Read More

8 Ways To Stay Motivated While Working with Kanban

There are quite a lot of different time-management systems when it comes to the manufacturing process but the Kanban is a particularly interesting one. Developed by one of the leading engineers of Toyota, the Kanban is a way of managing the entire supply chain in order to achieve JIT manufacture – this stands for just in time processes. It is particularly effective and yet quite challenging for both the managers and the employees. With this in mind, let’s take a look at a few things that need to be accounted for in order to stay properly motivated. 1. Self-awareness is important You need to be well aware of your own capabilities – what you can and can’t do. This is particularly important when it comes to staying motivated while working with this particular management system. This is going to enable you to assess your capabilities and know your limits. 2. Reach out to your colleagues The Kanban is known to be a system which relies thoroughly on social support. With this in mind, reaching out to your colleagues in times of need is something that you are going to have to resort to every now and then. 3. Mange your own energy Be thoughtful on how you spend your energy. A lot of the times you are going to be required to do repetitive work so make sure that every move is properly optimized. This is going to ensure that you make it through the entire shift without any issues. 4. Tweak all of your work habits Make sure that you have no unnecessary habits that manifest throughout the working time. This is particularly important and you need to take care of it. You’d be surprised to know how much energy you waste on things which aren’t even productive. 5. Roadblocks need to be reconsidered If there is a certain setback that you are concerned with, take your time to figure it out. If there is something that’s preventing you from handling the work appropriately make sure that you tweak it. 6. Be open to self-jokes Doing the same thing over and over again is going to get you thinking. Sometimes, you are going to do silly mistakes out of carelessness. Don’t worry – it happens. Be open to jokes and laugh at them – you need different experiences. 7. Savor your success When you get the task done from scratch you should celebrate. Of course, that’s not in the most literal meaning of the word. However, savor your accomplishments and enjoy them as much as you can. 8. Break your goals down You are going to be flooded with assignments – make sure to break them down in individual and achievable chunks. This is particularly important. The accomplishment of every single task is going to motivate you to keep going and that’s something which is of tremendous impact. As you can see, there are quite a lot of things that you might want to account for when it comes to handling repetitive management schemes.
Rated 4.0/5 based on 20 customer reviews
8 Ways To Stay Motivated While Working with Kanban

There are quite a lot of different time-management... Read More

The Evolution Of Kanban: A Study Of The Principles & Practices

As a part of the overall move towards Agile software development and related disciplines, many people are interested in Kanban. Some are applying it as a part of Agile, others are looking into it as an alternative to Scrum. There is a lot of confusion about this simple yet effective tool, so this article will clear up these misconceptions and provide a quick crash course into the essentials of Kanban. Where did Kanban come from? Kanban originated in Japan in the 1940s. People from the Toyota car manufacturer noticed that supermarkets used a simple but effective system based around small physical cards to indicate when something was out of supply or needed to be ordered. They applied this system in their own manufacturing process to help visualise work and control flow. Kanban became a part of Lean Thinking and the Toyota Production System. It was later popularised amongst software developers in 2010 by David Anderson with his book “Kanban: successful evolutionary change for your business”. What really is Kanban? Kanban is a simple but powerful system for visualising and managing work. It is not just related to software development, in fact, it is not specifically related to development of any kind. It can be used in a restaurant, a supermarket or a car factory. It has four principles and five practices. As opposed to Scrum, which involves revolutionary change, Kanban is about evolutionary change, starting from right where you are now (in fact, that is one of the fundamental principles: start off by changing nothing whatsoever! You won’t find any organisation on earth that will resist that change). It is fundamentally about visualising work and then finding ways to improve the flow of work through a system.   Nice visualization of the Kanban principles and practices pic.twitter.com/WbDMSoRfk5 — maciej sowiński (@maciej_sowinski) January 13, 2016 The Four Principles of Kanban This section will discuss the four fundamental principles behind Kanban. They are all essential to understanding and implementing the practices. Fortunately, they are simple and can fit into any organisation or system. Start with what you do now As mentioned, Kanban is a method for gradually improving an existing workflow or system. So you start with whatever you are doing now - whether simple or complex, big or small. You can use Kanban alongside or on top of any existing framework or system you are using - Scrum, Waterfall (yes Waterfall!), or anything, really. Many people believe they have to choose between Scrum or Kanban - untrue! You can use them together. Agree to pursue incremental, evolutionary change As opposed to systems like Scrum or Extreme Programming, that start out by fundamentally changing the structure and behaviour of organisations, Kanban is about evolutionary change, one small increment at a time. This can make it well-suited to cumbersome organisations that resist large risky changes. Respect the current roles, responsibilities, and titles Kanban doesn’t start off by renaming people or inventing strange new roles. Everyone gets to keep not only their job but their job title too. This further helps resistance to change. Encourage acts of leadership at all levels This is a subtle but very important principle. Improvement is the responsibility of everyone in the organisation, from the CEO down to the receptionist. You might get to keep your current job title and responsibilities, but you also now have an additional responsibility: leadership, which is really about empowerment and improvement. The Five Practices of Kanban Unlike Agile, which only has values and principles, Kanban has actual practices that you can employ, starting from day one. Visualise the workflow This is the most important step in all of Kanban, and is at the core of the whole system: visualising work. This was trivially easy to do in Toyota car manufacturing plants: the work was cars lying around in various states of semi-construction. For knowledge work like software development, marketing or design, it is much harder to visualise. This can let work accumulate and create huge blockages without anyone being aware. So visualise the work! This will make it easy to see where work is piling up and where problems and bottlenecks are. The best way to do this is on a physical board, using tokens such as index cards or post-it notes. Putting the work in an electronic tool might seem convenient but when the computer is switched off or minimised, the visualisation of the work is gone. The bigger and more physical, the better! You want to aim for information radiators (that push information out to the organisation) rather than information refrigerators (that preserve information away from people’s eyes). The most common way to visualise the work is with a Kanban board that has vertical swimlanes to represent states of work. You can then place cards on the board to represent the actual work item. Here is an example of the simplest of Kanban boards, with lanes for To Do, Doing and Done: Here is another example of a board, this time with some extra lanes, numbers that indicate Work in Progress Limits, and cards marked as being Blocked. Limit WIP Limiting WIP (WIP stands for Work In Progress) is another key practice of Kanban. People often think that we want to maximise work in progress - that means everybody is busy and lots is getting done, right? Well, if you have lots of WIP, then everyone will probably be very busy, but that isn’t really valuable. We want work in a Done state, not in a “Doing” state. And the best way to ensure that is to actually REDUCE the amount of Work in Progress! It might sound counterintuitive, but it is true. Lots of WIP means lots of handoffs, queues, bottlenecks and task-switching. This all means not much getting actually Done. Minimising WIP means you can maximise flow, which maximises the amount of work Done. And that’s the true goal. Manage Flow Kanban focuses on reducing WIP in order to maximise flow. If you want lots of work to get to Done but don’t want lots of work in a Doing state, you have to reduce the amount of time it takes for work to go from Doing to Done. This is called Cycle Time. Kanban practitioners have many tools they can use to improve flow and reduce cycle time, and these will often become clear after you have visualised the work. They include eliminating approvals and handoffs, swarming on complex slow tasks, identifying bottlenecks, putting WIP limits on Kanban lanes, reducing wait time between tasks, and reducing queues. Make Process Policies Explicit As you implement new rules and policies to improve flow, ensure you make these explicit. If you have a Definition of Done, get people to agree to it and publish it. If you change the rules about approving a document, make sure this is understood and explicitly described. Improvements will fall away and get misused if they are not clearly articulated and understood. Improve Collaboratively, Evolve Experimentally Improving is a collaborative team effort, not something randomly forced on people by some arbitrary management edict. It should be implemented by teams in an iterative experimental effort. Teams need to feel they are in an environment where experimentation is encouraged and it is “safe to fail”, or nobody will try making genuine changes. I hope you have enjoyed this crash course in Kanban - many people are using this system to great effect. If you want to know more, I would recommend the books Kanban by David Anderson, or Kanban in Action by Joakim Sunden and Marcus Hammarberg.  
Rated 3.5/5 based on 4 customer reviews
The Evolution Of Kanban: A Study Of The Principles...

As a part of the overall move towards Agile softwa... Read More