Sprint Planning

Frequency: Once per sprint

Meeting length: 2 - 8 hours

What is Agile Planning?

Agile planning is focused on getting the answers to simple questions like

• What is to be built?
• When will it be completed?
• How much will it cost and who should be involved?

The project managers also explore hidden dependencies for various activities to minimize the idle time and optimize delivery period. Agile planning revolves around measuring the velocity and efficiency of an Agile team to assess when it can turn the user stories into processes, production-ready software, and quality product delivery. The ultimate goal of Agile planning is to have a clear picture of project vision, production roadmap with sprint schedule, and business interests. To simplify the things, Agile planning can be stipulated of different levels;

• product vision
• product roadmap
• release
• iteration
• daily commitment.

Level 1: Agile Planning For Product Vision – Five Tips

Agile planning starts with product vision creation ensuring that strategies are aligned properly and the development team spends its time on creating the right valuable product. The product vision guides the team members for the shared goal like a lighthouse. The product vision statement tells about ‘how the product supports organization’s strategies.’ You can simplify the process of Agile product vision development by making it a four-step exercise – development, drafting, validation, finalizing. The following five tips will help you to get the most out of it:

• Product vision should deliver the unique feel of ownership to keep you motivated.
• Validate your product vision with all the stakeholders, Scrum team members, users etc.
• Develop the product vision iteratively & incrementally with the scope to make it better over time.
• The product vision pitch should address all the key concerns of different stakeholder groups pertaining to quality, product goals, competition, longevity and maintenance needs etc.
• Focus your product vision on the values for users and customers not merely on the most advanced technology.

Level 2: Agile Product Roadmap Planning– Five Tips

An Agile product roadmap is a plan that describes the way the product is likely to grow; it also facilitates for learning to change. To succeed in Agile management, you need to have a goal-oriented roadmap as it provides crucial information about everyday work by the team. As a powerful Agile management tool, it helps to align all the stakeholders and to estimate sufficient budget for quality product development as per schedule. Creating effective roadmap is often a challenge because changes occur unexpectedly in an Agile environment; however, the following five tips will help you plan the most effective roadmap:

• Do all the necessary prep work including describing & validating the product strategy. To know more about ‘Product strategy in the Agile world’, visit - https://svpg.com/product-strategy-in-an-agile-world/ .
• Focus your product roadmap on goals, benefits, objectives, acquiring customers, removing technical debt and increasing engagement etc.
• Let your product roadmap tell a coherent story about the likely development of a product. To simplify the task, you can divide the product roadmap into two parts- internal product roadmap and external roadmap. The internal product roadmap is focused on development, service, supporting groups, marketing, sales etc; while, the external roadmap is focused on prospective & existing customers.
• Keep the product roadmap simple and realistic to make the features understood by everyone concerned.
• Make your product roadmap measurable; so, think twice before adding timelines and deadlines.

Level 3: Release Planning – Five Tips

In Agile landscape, the release is a set of product increments released to the customer. The release plan defines how much work your team will deliver by the mentioned deadline. Release planning is the collaborative task involving Scrum master (facilitates the meeting), Product owner (shares product backlog view), Agile team (provides insights into technical dependencies & feasibility) and Stakeholders (the trusted advisors). The following five tips will help you in effective release planning:

• Focus on goals, benefits, and results.
• Take dependencies and uncertainties into account.
• Release early but don’t release just for the sake of scheduled releasing.
• Only release the work that is ‘Done’. To know more about ‘Definition of Done (DoD)’ in Agile, plz visit - https://www.knowledgehut.com/blog/agile-management/definition-of-done-use-in-agile-project .
• Each release process has the scope for betterment. Continuous release process improvement helps you deliver more values for the product.

Level 4: Iteration Planning - Five Tips

The iteration planning is done by holding a meeting, where all the team members determine the volume of backlog items they can commit to deliver during the next iteration. The commitment is made according to the team’s velocity and iteration schedule. The following five tips will help you in effective iteration planning:

• Span the iteration planning meeting maximum up to 4 hours.
• The planning meeting is organized by the team and for the team; so, everyone should participate.
• Avoid committing anything that exceeds the historical team’s velocity.
• Keep time for ‘retrospectives’ in the past sprints before planning for the next one. To know more about ‘Agile retrospective’, visit - https://www.agilealliance.org/glossary/heartbeatretro/.
  Follow the four principles prepare, listen, respect & collaborate

Level 5: Daily Commitment Planning– Five Tips:

Like many other planning activities for Agile management, the daily commitment planning also needs the synchronized partnership of teams. The daily planning meeting is focused on completing the top-priority features. The 15-minute standup meeting facilitates face-to-face communication on individual’s progress and impediments if any. The following five tips will help you in progress-oriented daily commitment planning:

• Keep it around the task board.
• Start on time regardless of who is present or not.
• Let each team member go through the questions like - what he did yesterday, what is his plan for today, and, is there any impediment?.
• Use ‘Parking Lot’ for the unresolved issues. The purpose of daily Agile-Scrum planning is to let the team members know about ‘being done’, ‘needs to be done’ and ‘hindrance if any’. Anything out of this scope should be listed in ‘Parking Lot’ to be dealt later.
• Do preparation ahead of time. The team members should know ‘what they need to share’.

Daily Scrum Meeting

Frequency: Daily

Meeting length: 10 - 15 minutes

Scrum meetings are a part of agile meetings, or scrum ceremonies, where all team members can sync up on the work they did in the last 24 hours, and go over what’s on deck for the next 24 hours.

Daily Scrum Meeting Checklist

Blockers

Is there anything preventing contributors from getting work done? Things to bring up here might be technical limitations, departmental and team dependencies, and personal limitations (like vacations booked, people out sick, etc.).

What did you do yesterday?

This is a quick rundown of what got done yesterday (and if anything didn’t get done, then why). This isn’t the time for each person to run down their whole to-do list – they should focus on the large chunks of work that made up their deep focus time, and the activities that are relevant to your team as a whole.

What are your goals for today?

Here, each team member will say what they want to accomplish – in other words, what they can be held accountable for in tomorrow’s daily scrum meeting.

How close are we to hitting our sprint goals? What’s your comfort level?

This agenda item will help the scrum master get an idea of how the team is feeling about how their day-to-day activities are impacting overall goals for the team, and how contributors are feeling about the pace of the sprint.

What to avoid in your daily scrum?

Lateness

Being late for any meeting is disruptive, but it’s particularly distracting when the meetings are only 10 minutes long. Hold your team accountable for being on time, every time.

Monopolizing the conversation

Giving each team member the opportunity to talk is hugely important. Reinforce this at the start of each scrum if you find that certain team members have a tendency to ramble on.

Over-formalizing the process

Don’t over-complicate your scrum meetings. Keep the agenda the same each time you meet, and make the technology for meeting consistent. Daily scrum meetings involve less than 10 minutes of meeting prep, max.

Other daily scrum meeting tips:

• Hold your daily scrums in the morning and at the same time each day
• Do you daily stand-ups in person (standing up) where possible. If that’s not possible, use a reliable and consistent tool for communicating remotely (we love a good Slack Bot for this).
• Let the team lead the conversation
• Be a time cop and don’t let your stand-ups run more than 10 minutes

Referenced from here.

Sprint Review

Frequency: Once per sprint

Meeting length: 1 - 4 hours

Sprint Review or a Demo?

Many of those practicing Scrum mistakenly call the Sprint Review a Demo. Is it just a matter of terminology? From my point of view, the Sprint Review is the most underestimated Scrum Event, and for many companies, its potential is yet to be revealed. It is true that the Demonstration or Demo is an essential part of the Sprint Review, but it isn’t the only one.

The Sprint Review is much more than just a Demo.

Let’s find out why.

Who attends the Sprint Review

The Scrum Team and stakeholders (users, other teams, managers, investors, sponsors, customers, etc.) One could say that we invite the whole world to the Sprint Review and this is absolutely true.

How the Sprint Review Is Conducted:

• The Product Owner opens the meeting and tells the attendees what the Development Team completed during the current Sprint (what has been “Done” and “not Done”).
• The Development Team demonstrates the “Done” functionality (Demo), answers the questions and discusses problems they met on their way.
• The Product Owner discusses the current state of the Product Backlog, marketplace changes, and forecasts the likely release dates.
• The attendees collaborate on the Product Backlog Items, which can be completed during the next Sprint. Thus, the stakeholders get a shared understanding of the future work.
• A review of the budget, timeline, potential capabilities follows.

The Opportunity To Inspect And Adapt.

Sprint is one of the five official Scrum Events and is an opportunity for the Scrum Team to practice empiricism. Here is a short summary of what we inspect and adapt during the Sprint Review.

Inspect: Sprint, Product Backlog, Increment, Marketplace, Budget, Timeline, Capabilities.

Adapt: Product Backlog, Release Plan.

Inspecting Is Much More Than Just An Increment.

The Sprint Review is not just about product demonstration, it is an inspection of the completed Sprint, the Product Backlog and the marketplace. Also, it is a place for reviewing budgets, timeline and capabilities. Each Sprint is an important risk mitigation tool and the Sprint Review is a decision point for the Product Owner.

Each Sprint can be the last one. The Product Owner makes a formal decision regarding financing the next Sprint during the Sprint Review.

Here are some decisions that can be formally made:

• Stopping/Pausing the development
• Financing the next Sprint
• Adding team(s) with an assumption that it will speed up the development
• Releasing Increment (can be done anytime during the Sprint)

Is My Sprint Review Good Enough?

Scrum is based on iterative and incremental development principles, which means getting feedback and making continuous updates to the Product Backlog. Unfortunately, teams often forget about it.

The Sprint Review is a great tool for getting feedback, while the number of changes to the Product Backlog after the Sprint Review can be an important indicator of how healthy your Scrum is.

Why Many Scrum Teams Don’t Go Beyond Demo

Many teams/companies underutilize the entrepreneurial spirit of Scrum and its concept where the Product Owner is a mini-CEO of the Product. Very often, stakeholders attend only the Increment demonstration (usually done using a projector) with few questions asked and then everybody leaves shortly afterwards. This may happen for several reasons:

• The Product Owner doesn’t actually “own” the product, cannot optimize the ROI or make strategic decisions about the product, and is, in fact, a Fake Product Owner (FPO). During the Sprint Review, stakeholders (with actual Product Owner among them) often “accept” the Scrum Team’s work.
• The company’s business and development departments continue to play the “contract game” with predefined scope and completion dates. In this case, the Sprint Review inevitably becomes a status meeting.
• Superficial Scrum implementation at the company.
• The Product Owner doesn’t collaborate enough with stakeholders.
• This is a case of “fake Scrum”, when the Scrum Team handles only a part of the system with inputs and outputs and not the real product. There is nothing to show and nothing to give feedback on.

Good Sprint Review Practices

• An informal gathering with coffee and cookies that looks more like a meetup, often held as an Expo or a Review Bazaar.
• The Product Backlog is updated after/during the Sprint Review.
• The meeting is often attended by the end users.
• The Development Team communicates directly with end users and stakeholders and gets direct feedback from them.
• The “Done” product is showcased on workstations where the stakeholders can play with the new functionality.

Signs of An Unhealthy Sprint Review

• A formal/status meeting.
• The new functionality is demonstrated only in a slide show.
• The Product Owner “accepts” the work completed by the Development Team.
• The Development Team isn’t (fully) present.
• Neither are stakeholders and/or end users.
• The demonstrated functionality does not meet the Definition of “Done”.
• The Product Backlog is not updated. The Scrum Team works with a predefined scope.
• The stakeholders “accept” the completed work from the Product Owner.

The Bottom Line

Well, I wrote quite a lot. Let’s sum it up.

• The Sprint Review is more than just a Demo. The Sprint Review is a place to discuss the marketplace changes, examine the completed Sprint as an event, update the release schedule, discuss the Product Backlog and the possible focus for the next Sprint. This is where the dialog between the Scrum Team and the stakeholders takes place and feedback on product Increment is obtained.
• The number of changes to the Product Backlog can be an important sign of how healthy your Scrum is.

Sprint Retrospective

Frequency: Once or twice per sprint (Not mandatory)

Meeting length: 1 - 4 hours

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.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. This is the opportunity for the Scrum Team to improve and all member should be in attendance.

During the Sprint Retrospective

The team discusses:

• What went well in the Sprint?
• What could be improved?
• What will we commit to improve in the next Sprint?

Expected Output

The Scrum Master encourages the Scrum Team to improve its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done” if appropriate and not in conflict with product or organizational standards.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Backlog Refinement (Grooming)

Frequency: Once or twice per sprint (Not mandatory)

Meeting length: 2 - 4 hours

Backlog refinement (formerly known as backlog grooming) is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.

Backlog Refinement Checklist

Prioritization

Items should be discussed and prioritized based on customer / market needs.

Decomposition of Items

The issues should be completed within a sprint, thus, if there are any issues that are not

Cleanup of Deprecated Items

Some of the issues may be deferred due to change of requirements or necessity of that feature, thus, cleanup of the backlog items can be done here.

What to avoid in your grooming?

Planning

This has its’ own meeting, attendees should not discuss the sprints that these items will be developed.

Old Issues - Completed Sprints

This meeting is to clean the backlog, completed items are not in scope of this meetings.

Performance and Forecasting

These can be done during retrospective, this has nothing to do with the grooming meetings.

Other grooming tips:

• PO can discuss priorities and requirements with stakeholders before the meeting.
• Weight (or any other measurement types) can be added during this meeting.
• Not everyone is needed in this meeting.

Referenced from here and here

Sprint

Frequency: Daily

Duration: 1 - 4 weeks

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

No changes are made that would endanger the Sprint Goal; Quality goals do not decrease; and, Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

Concepts