Common Misconception

Most people treat Sprint Review as a “gate check” forum to release the product into production. Thus, the Sprint Review ends up being a formal meeting with gate-checking checklists to go through so that the product can be sent to production.

What really is a Sprint Review?

• Sprint Review is an informal forum to seek feedback from the Stakeholders
• Intention of the Sprint Review is for the Scrum Team to find out if they are on track to meet the Product Goal, and if not, inspect and adapt the Product Backlog for future Sprints
• Scrum de-links the “go-live” or “delivery to stakeholders” and “seeking feedback”. Sprint Review’s intent is to seek feedback. The product may be delivered to the stakeholders before or after the Sprint Review

Recommendations

• Sprint Review should be a informal discussion between Product Owner, Stakeholders and Developers to discuss improvements in the product and increase the probability of reaching the Product Goal
• Sprint Review should be more like a working session instead of formalized presentations and checklists to go through
• It is better to create a separate gate check forum other than the Sprint Review. If any gate checking is done in Sprint Review, the real intent of getting feedback may be lost

Conclusions

Sprint Review is not a gate checking forum. It is a working session where Scrum Team and Stakeholders collaborate on how better to achieve the Product Goal

The post Myth – Sprint Review Being a Gate to Releasing Value appeared first on World Of Agile.

Common Misconceptions and Negative Implications

·        It is a common practice for a Product Owner to come up with a set of requirements in the Sprint Planning and disappear during the Sprint. Then appear directly at the Sprint Review forum and conduct the review of the Developers work during the Sprint Review.

·        By doing this, an important opportunity of giving feedback continuously is lost. The feedback becomes a big-bang-end-of-the-sprint activity

·        Since Product Owner is seeing the product first time during the Sprint Review, it can become difficult to take feedback from stakeholders

·        If Product Owner brings along the stakeholders to do a Sprint Review, the Product Owner ends up acting like the “Other party” and does not build confidence in the team doing the work

• When the Product Owner sees the newly increment only at review time, Sprint Review becomes a gate that holds back value from reaching the users. When the Product Owner sees the increment during Sprint an opportunity is created to release value earlier

Recommendations

·        The Product Owner owns the product. Therefore, it is important for the Product Owner to participate in the product development continuously and constantly provide feedback.

·        The Product Owner has to build confidence with the Developers. Developers being left alone is not a great idea. The Product Owner should not behave like an outsider and should not sit on the other side of the table. Once the Product Owner wears the “Product Owner Hat”, he/she is first part of the Scrum Team and then part of the Customer or Client or Stakeholder team

·        Developers must not fear the Product Owner. Feedback is not a cause for worry. Feedback is good. The earlier you receive the feedback, the better it is for the Product

·        Typical steps in the Sprint Review that are seen useful by many teams could be as below

o   The Product Owner should invite the relevant stakeholders for a Sprint Review

o   During the Sprint Review forum, the Product Owner should sit with the Developers

o   The Product Owner should thank the Developers in front of the stakeholders for the work done

o   The Product Owner should take ownership of the product during the Sprint Review and collaborate with stakeholders to make it a working session

o   During the Sprint Review, the feedback should be from Stakeholders and not from the PO. The PO feedback is assumed to have been taken already during the Sprint

o   The stakeholders and Product Owner should think about the next steps based on market place conditions and make adjustments to the Product Backlog

Conclusions

·        Sprint Review should be a working session between entire Scrum Team and Stakeholders

·        Product Owner should be reviewing the product with stakeholders with help of the Developers

·        Product Owner should have provided feedback to the developers continuously throughout the Sprint and should not be seeing the product first time during the Sprint Review

The post Myth – Sprint Review being the review of the Developers done by Product Owner appeared first on World Of Agile.

It is a common mis-conception that Scrum is only useful for small projects.

The real fact is that Scrum is used for solving complex problems. Complex problem is a problem where there are “unknowns” about requirements or the solution.

For solving complex problems, the decisions have to be taken based on what has been done in the recent past. It is extremely difficult to base your decisions based on long-term assumptions. This way of solving problems is called Empiricism or Empirical process control. Scrum is a framework based on Empirical Process Control Theory and therefore, used for solving complex problems.

A complex problem may be big or small. Therefore, the size of the problem has nothing to do with usage of Scrum or other frameworks/methods. A few examples of massive complex problems

• Merger or separation of a bank – When two banks merge or separate, there are a lot of unknown factors on the products in the resultant merged or separated bank. For example, one bank may be a risk-taking bank have an investment product based on a mix of equity, commodities, and derivatives, whereas, second bank might have a more conservative approach based on fixed-deposits, company-fixed-deposits of blue-chip companies and debt market involving only government securities. Now what would be the product applicable for the new merged bank? Would both products be offered by the new bank or would they be another combination product, or if the merged bank carries the image of the conservative bank then should it even offer the risky product? There are a lot of unknowns here. Would the image of a new merged bank be conservative or risk taking? Would the customers of the risk-taking bank accept the conservative products? Would the customers of the conservative bank accept the risky products or accept a risky profile of the new merged bank? This is an example of an unknown scenario. Unless things are tried out, there is no way you could take decisions. As a business, you may try various combinations, but the answers are possible only after trying different products and taking feedback from customers.
• Development of a medicine or vaccine for an unpredictable disease – The whole world grappled with the Covid-19 pandemic in 2020. The solution to solve this problem was two-fold – either develop a vaccine to prevent the disease or develop a medicine to kill the virus if anyone gets infected. Both were big unknowns. How the infections spread was unpredictable and also how the disease affects the patients was also unpredictable. Scientists and researchers had no option but to use the trial-and-error approach based on the past knowledge of various viruses. However, the majority of the decisions were based on what was the result of the trails done on various animals and eventually on human beings. Again a complex problem where decision can only be taken based on what has been done in the recent past. The decisions cannot be taken based on long-term planning.

Naturally, the approach for solving these kinds of problems is to shorten your planning horizons, try out things, if things do not work then try something else, if things work then try something else to make the solution stronger. So isn’t Scrum a way of solving such problems? Scrum shortens the planning horizon to maximum one month, then uses the inspect-adapt cycles (at the bare-minimum) through Sprint Reviews, Daily Scrums and Sprint Planning. The implementation of the Product Backlog is in-fact a way of adapting the requirements as you move forward and as more is known about the problem you are solving.

Therefore, it is a myth that Scrum is for small projects.

Conclusion

The size of the project has nothing to do with the use of Scrum or not.

• Scrum is based on Empirical Process Control Theory.  Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
• Scrum combines four formal events (Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective within a containing event, the Sprint) and three Artifacts (Product Backlog, Sprint Backlog and Increment) to implement empiricism. These events work because they implement the empiricism pillars of transparency, inspection, and adaptation.
• Thus, Scrum is being used for solving complex problems (unknown requirements or unknown solutions) for small as well as large projects where constant inspection and adaptation is necessary and decisions have to be taken based on what is observed. Scrum Team observes what is happening based on the feedback received and adapts to the changes.

The post Myth about Scrum only being useful for small projects appeared first on World Of Agile.

Common Misconceptions and negative implications

Sprint Review is thought to be a “sign-off event by the Product Owner” or “a demo forum by developers” by most organizations. This is an INCORRECT understanding of the Sprint Review.

Sprint Review is actually a feedback solicitation forum. The Scrum Team seek feedback from the stakeholders during the Sprint Review. This helps address the deviations. The Product Owner and Developers work together on a day-to-day basis. The Product Owner DOES NOT wait till the end of the sprint to give feedback to the Developers.

Recommendations

• Product Owner needs to participate during the Sprint and provide feedback throughout the Sprint to the team. This gives an opportunity to the team to work on the feedback by the PO and adapt if required. This also gives opportunity for the PO to get the product ready by the time the Sprint ends.
• Product Increment is considered as an INPUT into the Sprint Review and not an output as thought by many people. Therefore, sign offs (if any) have to be done before the Sprint Review starts. Also the sign-off – if anyone has to do – it has to be the Product Owner. That’s why the word “Owner”.
• When the Sprint Review starts, the Product Owner and Developers have to be in sync with what is being shown to the stakeholders. If both the roles are in sync, then Sprint Review becomes an excellent opportunity to solicit feedback from stakeholders – who could be sales teams, marketing teams, sponsors, end-user representatives etc.
• If one wants to use the word “Demo”, then my recommendation is to use the word during the Sprint when Developers demos the product continuously and seeks feedback from the PO. Demo should be ongoing and day-to-day where-as the Sprint Review is the minimum opportunity to solicit feedback from stakeholders.
• Some may argue that getting Increment is impossible considering that stakeholder feedback happens in a Sprint Review. What we really recommend is that Sprint Review should be a “minimum” forum to seek feedback from stakeholders. Scrum does not stop you from getting more feedback from stakeholders during the Sprint.
• The objective of the Sprint is to get a “usable” Increment at the end of the Sprint. This is possible if feedback is taken frequently from stakeholders – at a bare minimum during the Sprint Review. The Product Owner feedback should be day-to-day

Sprint Review therefore, is an informal opportunity for the Scrum Team to solicit feedback from stakeholders and make sure that the deviations are addressed.

The post Myth about Sprint Review being a sign-off event or a demo forum appeared first on World Of Agile.

Common Misconceptions and negative implications

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing a SoW or a contract.

Recommendations

• Scrum Guide recommendation is to keep the Sprint Length “Consistent”. Scrum Guide does NOT recommend a “Fixed” Sprint Length. We can change Sprint Length if there are negative implications being caused because of incorrect Sprint Lengths.
• Considerations for changing the Sprint Lengths
• Changing Longer Sprint Lengths to shorter Sprint Lengths (say 4 weeks to 2 week)
  • The scope keeps changing during the Sprint and Sprint Backlog becomes a mess. What we started off at the time of Sprint Planning and what we ended up in a Sprint Review is drastically different
  • Teams develop a “student syndrome”. Means – team takes it easy for the first couple of weeks. Then goes for a dash to the finish. The team then ends up working 18 hour days for last 2-3 days
  • The feedback is so drastic each Sprint Review that you need to re-work the whole thing. Think about the Sprint Length if this happens frequently.
  • Teams and PO don’t speak to PO often and communication breaks down resulting in no or minimal feedback during the Sprint.
• Changing Short Sprint Lengths to Longer Sprint Lengths (say 1 week to 4 week)
  • Teams come under a huge stress. Deliverable every Friday is not easy. The stress levels take a toll and teams get sick of the stress.
  • Innovation goes down with very short sprint lengths. Teams become very “short-term” focussed.
  • Dividing items into smaller units becomes difficult. Beyond a point, breakdown of Product Backlog Items becomes a formality/academic rather than a real need.
  • Spilled-over work to next Sprint becomes common with very short sprint lengths. Teams are unable to create something useful.
  • Motivation goes down because of stress levels or not being able to get the Sprint to produce something usable every Sprint or stakeholders constantly feeling upset about not being able to complete.
• DISCLAIMERS SO THAT YOU DON’T MIS-UNDERSTAND OUR STATEMENTS ABOVE
  • DO NOT keep changing the Sprint Lengths often. Try a Sprint Length, see if it works. If it does not work, then change. Once you find a length which is solving most of the problems, then stick with it. Be CONSISTENT. Being able to change the Sprint Length does not mean you become random and chaotic in the way you work.
  • DO NOT think that there is a “PERFECT Sprint Length”. There can never be a “Perfect Sprint Length”. See what Sprint Length solves “MOST” of your issues.
  • DO NOT change the Sprint Length when you are inside the Sprint. Just because you are not completing a Scope, does not mean, you change the Sprint Length by extending it. Sprint ends when a Timebox ends. You may think about changing the Sprint Length from the next sprint onwards.

The post Myth about baselining the Sprint Lengths at the start of the project and never changing it appeared first on World Of Agile.

Sprint Review

At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”. This section describes the Sprint Review Meeting and next section describes the Sprint Retrospectives. One must understand that the objectives of both meetings are very different.

At the Sprint Review Meeting:

• Attended by Product Owner, Scrum Master, team and other stakeholders as required
• The objective of this meeting is

o   To review the work that was completed

o   The planned work that was not completed

o   If the team is on track

o   Get Feedback

• Present the completed work to the stakeholders (“the demo”)
• Incomplete work cannot be demonstrated
• Four-hour time limit
• Feedback from participants are reviewed and recorded. The product owner should consider the feedback as potential backlog items

Best Practices at the end of Sprint review

• Items which were not completed are added back to the Product Backlog.
• Product Owner should assess the priorities of feedback and add to backlog if necessary
• If the customer wants to feel the product, the Product owner should consider making a partial release (Alpha or Beta release) so that the customer can play around with the product.
• It is a good practice to record the demo and make it available to the participants who could not attend the review

Handing Sprint Reviews

• Communicate effectively: Team members who are most able to communicate effectively with the team, Product Owner, Scrum Master, and stakeholders should present, so that they can represent the team in front of the customer.
• Fluent speaker: Another approach is to record the demonstration before the meeting to allow the developers to create the recording at their own pace in the language of the meeting, or to have a fluent speaker speak over the recorded demonstration.
• Scheduling for teams with overlapping work hours: Make sure all team members of the distributed team, regardless of the time zone, can complete their work and prepare for the demo within overlapping work hours.
• Scheduling for teams with no overlapping work hours alternate meeting time: The distributed team holds one sprint review meeting during the normal workday for part of the Scrum team and holds the other sprint review meeting during the normal work hours of the other part of the Scrum team.
• Keeping track of the stakeholder comments: During the sprint meeting, the distributed team needs to capture these comments so the product owner and the developers can decide which ones they will act on.
• Remote demonstrations: Distributed teams should test their tools ahead of time to be sure the distributed meeting will run smoothly, without network poor performance. The team can also consider making the recordings available for download before the demonstration meeting and discussing them through a teleconference.
• Services may vary by location: Set up a single machine with a standard configuration that everyone uses during the demonstration meeting. Before the start of the meeting, distributed team members can access the machine (remotely or locally) to bookmark links, set up scripts, and do a quick dry run of their presentation

For many myths around Sprint Review, refer to following articles

• Myth about Sprint Review being a sign-off event or a demo forum

The post Sprint Review appeared first on World Of Agile.

Scrum Events

Scrum Events are mandatory opportunities given by Scrum to Inspect and Adapt. The reason they are mandatory is that Scrum is a inspect-adapt way of solving complex adaptive problems. If we do not use the minimum opportunities then a fundamental aspect of Scrum is compromised. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

Scrum Events create regularity and minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

There are 5 Events in Scrum

• Sprint – which is container of all the other events
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Following is the summarization of all events

The post Scrum Events appeared first on World Of Agile.

What is a Sprint retrospective?

The Sprint Retrospective is the event in Agile which brings in the iterative, inspective and adaptive nature into picture. The team reflects upon the previous timebox with a view to learn some lessons, adjust the behavior or environment in order to improve their experience.

A Sprint Retrospective is a special meeting that takes place after each iteration, in which the team members gather to inspect and improve their methods and teamwork.

Since Sprint Retrospectives happen during the project, the lessons and improvements that result from them are applicable and relevant to upcoming work on the same project.

Advantages of Sprint Retrospectives include the following

• Improved Productivity : By applying lessons learned and reducing rework, the team can get more productivity work done.
• Improved Capability : Sprint Retrospectives provide a venue for spreading knowledge, so does the number of people who can perform tasks associated with the knowledge.
• Improved Quality : We can improve quality on our projects by finding the circumstances that led to defects and removing the causes.
• Improved Capacity : Retrospectives focus on finding process efficiency improvements, which can improve the team capacity to do work.

Why is a Sprint Retrospective important?

Sprint Retrospectives are important because they gives the team visibility into issues and helps them to take action to correct course and make work environment more efficient and more productive.

• Sprint Retrospective is a 1-3 hour meeting at the end of the Sprint/Iteration.
• Typically, this meeting is held after the Sprint/Iteration Review Meeting. This helps the team to review what is working and what is not.
• Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
• Team then can take actions going forward
• All team members reflect on the past sprint
• Make continuous process improvements
• Mandatory attendees are Product owner and the Teams. Sometimes you may invite the Scrum Master  also.
• To bring in a neutral viewpoint, you may want to bring in a unbiased attendee also such as a Scrum Master of another team

What is not the objective of Retrospective

• The Sprint retrospective is a meeting “By the Team” and “For the team”
• It is not a performance review by senior Management
• Nor is it a postmortem meeting where the goal is to assign blame

The post What is a Sprint retrospective? appeared first on World Of Agile.

Best Practices around handling Sprint Review Meeting

• Communicate effectively: Team members who are most able to communicate effectively with the team, Product Owner, Scrum Master, and stakeholders should present, so that they can represent the team in front of the customer.
• Fluent speaker: Another approach is to record the demonstration before the meeting to allow the developers to create the recording at their own pace in the language of the meeting, or to have a fluent speaker speak over the recorded demonstration.
• Scheduling for teams with overlapping work hours: Make sure all team members of the distributed team, regardless of the time zone, can complete their work and prepare for the demo within overlapping work hours.
• Scheduling for teams with no overlapping work hours alternate meeting time: The distributed team holds one sprint review meeting during the normal workday for part of the Scrum team and holds the other sprint review meeting during the normal work hours of the other part of the Scrum team.
• Keeping track of the stakeholder comments: During the sprint meeting, the distributed team needs to capture these comments so the product owner and the developers can decide which ones they will act on.
• Remote demonstrations: Distributed teams should test their tools ahead of time to be sure the distributed meeting will run smoothly, without network poor performance. The team can also consider making the recordings available for download before the demonstration meeting and discussing them through a teleconference.
• Services may vary by location: Set up a single machine with a standard configuration that everyone uses during the demonstration meeting. Before the start of the meeting, distributed team members can access the machine (remotely or locally) to bookmark links, set up scripts, and do a quick dry run of their presentation

The post Handling a Sprint Review Meeting appeared first on World Of Agile.