Levels of Agile Planning

Levels of Agile Planning

It’s a frequent misconception that Agile methodologies necessitate a lack of planning, with teams jumping right into development without any prior planning. Planning at higher levels in the business, regardless of the Agile process, is a crucial input into what happens at the Team level.

Vision Planning

• Is the product’s or service’s overall goal or purpose.
• Is a high-level representation of the product or service.
• In a concise manner, communicates the essence of the product.
• Stakeholders are in agreement and understand each other.

The top layer of Agile Planning is the Product Vision. The Vision presents a compelling vision of the future. The Product Owner or Customer, in collaboration with any stakeholders, leaders, Subject Matter Experts (SMEs), and others, helps to capture the vision. Most essential, the Customer or Product Owner communicates the Vision to the Development Team, who will be responsible for carrying it out.

There is no standard template or method to capture the product’s vision, but much of the agile community has adopted Geoffrey Moore’s elevator pitch template from his book Crossing the Chasm.

 It’s Short, and easy for most product owners to capture a concise vision and share it with the development team.

The name comes from the fact that someone should be able to tell this in minutes or in the time it takes to get on the elevator to answer the question “what are you working on?”   The important thing is not the template, but the vision that everyone understands and agrees with. If the development team doesn’t know where the vision is or what it is,  the product owner doesn’t articulate it or share information. Some Scrum teams print vision statements and post them prominently, such as on the walls of team spaces or next to task boards. Sharing the Vision There is no set-in-stone manner to foster the item Vision. The significant thing to note is that one exists and everybody comprehends and settles on what it is. The Product Owner is liable for articulating the Vision. The PO works with key partners, Subject Matter Experts (SMEs), and the Development Team. The Development Team should know what the Vision is and where it is. In the event that they don’t then the Product Owner has not obviously expressed or shared it. A few Teams have Vision articulations printed out and posted noticeably in the mass of their Team region, close to task sheets.

Product Owner Must Examine and Communicate the Vision to:
The Development Team, The Stakeholders, The Organization.
Pick a technique to report the Vision: Project Charter or comparative report, Business Case, Cost/Benefit Analysis, or Business Model Canvas. Format / Template.

Roadmap Planning

Vision planning can occur at any time in an organization’s fiscal year. Maybe this was an idea previously identified or it’s in response to a competing product or service or the result of research, customer focus groups, etc. The Vision or idea then drives the Roadmap. At a high level, the organization must decide what its priorities are for products, initiatives, etc. It is important to note that at the Roadmap level, we have not engaged the people who will be doing the work who can best tell us how long the work will take. For that reason, Roadmap plans are high-level goals and not exact dates. Instead, it is expressed at the quarter level (Q1, Q2, etc.) or perhaps the time of year (e.g., the first half of the year, the second half of the year). The Product Owner is responsible for keeping the Roadmap current and visible to the Team executing it. The Product Roadmap provides the link between the Product Vision and the strategy for executing that Vision and it must be communicated to the organization, stakeholders, and the Development Team. Keep the Roadmap simple and easy to understand.

Roadmap Planning

• Typically takes place after establishing the Vision.
• Ensures priorities are aligned at all levels including the Scrum Teams executing the Vision.
• Is not necessarily a step in Scrum or other Agile methods but has been widely adopted.
• Is visualized in a Product Roadmap.

The Product Roadmap is a significant level time period that shows how the item will evolve across time. It just expresses the fundamental and requested significant level achievements for the product(s) and permits the Scrum Team and the organization to concentrate on the Product Backlog from Vision through execution. The Roadmap can be utilized to work with a discussion between partners, the Product Owner, and the Scrum Team.

The above picture is an illustration of a Roadmap. The Product Owner concludes what elements to push ahead within the following adaptation, gets financing, and holds Release Planning to start off the following stage.

The Roadmap is not a one-time activity, It is subject to change as the product owner or stakeholders or organizations need to respond to the customer, The Roadmap should consistently be assessed, moving as new things hit on the plate and others might drop off.
At the point when the Roadmap changes, the Product Owner should ensure the Development Team is familiar with the changes.

Release Planning

Arranging numerous Sprints or Iterations to foresee when a Release (or Releases) may be conveyed.
Happens regularly on a case-by-case basis to construct the establishment on which to convey the Vision.
A few Teams or organizations have quarterly, month to month, week by week, or all the more oftentimes planned Releases, and different Teams or companies may Release more frequently

Release Planning is held once an Item that has been ordered on the Roadmap is ready to kick off. The Release Planning session gives us the opportunity to see how many features, or which features, on our customer’s list can be delivered by a specific date, given a specific budget and/or Development Team.

A Release is made up of multiple Sprints or Iterations. Release Planning can occur any time a new product is kicking off. Some organizations standardize on their Releases to production (i.e., once per quarter), in which case Release Planning can fall in sync with that schedule. Many who do quarterly Releases invest a full 6 or 7-hour day on this session to be able to frame up the Release. It can take less time based on the size of the feature list or Product Backlog.

The Product Owner facilitates the Release Planning session. Release Planning cannot take place if the Product Owner is not ready and has no ordered Product Backlog. The Scrum Master may coach the Product Owner on getting ready for this session or co-facilitate to keep it moving.

Key Inputs to Release Planning are:
•Vision and Roadmap.
•Product Backlog ordered by business value.
•Scrum Team working agreements on estimation approach.
•Velocity,

If the Team has worked together on a previous Agile product. If these items are not available, the Scrum Team is not ready for Release Plan

During the Planning

• The Product Owner describes and facilitates discussion on each Story or Product Backlog Item.
• The Development Team has a timebox for discussion; typically five minutes per Story.
• At the end of the Discussion timebox, the Development Team estimates.
• The Scrum Master timeboxes everything to keep the meeting on track.

If all the inputs are available, we are ready to hold Release Planning. This is not a tasking session, nor is it a detailed design session. It is a high-level planning session in which we are discussing just enough detail to provide rough order-of-magnitude sizing.

The Product Owner typically reads or explains a Product Backlog Item or User Story.

The Development Team is given a timebox for discussion—typically about 5 minutes per Story.

When the time is up, the Development Team estimates the work based on complexity and effort relative to similar work: •They should have agreement on what their “baseline” is.

• What’s the definition of “Small,” for example, or “5 points?”
• If they have Stories identified to continue to compare back to, this process will be much more efficient.

Scrum Masters help keep this whole thing moving and ensure that all the players are prepared.

There is no prescription for who captures information in this session, but it does need to be captured. Acceptance Criteria that come out of the discussion, the resulting estimate in Points or T-shirt size, etc.

A Release Planning session is not a large effort, nor does it need to be. It shows the order of Stories, approximately where they will fall in the Sprints. The Release Plan is always subject to change based on reordering, results/actual progress, and changing business conditions. It is updated after each Sprint to reflect reality as it emerges.

This is an example of a Release Plan. It is not a large plan such as a Microsoft Project plan. It is enough to give visibility to the priority order of the Stories, and approximately where they fall in the Releases’ Sprints. We do not want to waste time on items in the Sprint that begins on July 5 now in June because something in our business may change and the Product Owner may take that item off the plate and replace it with something else.

This type of planning allows the Development Team to focus on what is the highest priority and to get it done by the end of the Sprint and then shift focus to what is next in priority.

The Product Owner always needs to be refining the Backlog and staying ahead of the Development Team, so that when it is the next Sprint Planning time, he or she can ask the Development Team to work on only the next highest priority items and not waste time/cycles.

Sprint Planning

Sprint Planning is an event that occurs at the beginning of each Sprint to answer what the Team will do in the Sprint and how they will do it. Attended by the Product Owner, Scrum Master and Development Team.

It is time-boxed to take a maximum of 8 hours for a 4-week Sprint. Shorter Sprints usually have a shorter Sprint Planning event. During Sprint Planning, the Team forecasts the amount of work they can do.

Sprint Planning answers the following questions: •What can be delivered in the Increment resulting from the upcoming Sprint? •How will the work need to deliver the Increment be achieved?

The entire Team is involved in Sprint Planning and agrees to complete a set of Product Backlog Items. The Product Owner discusses the objective that Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.

The input to this meeting is the Product Backlog, the latest product Increment, the projected capacity of the Development Team during the Sprint, and the past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

We walk into the Sprint Planning event with a refined Product Backlog, the historical velocity of the Team and the Development Team’s capacity, the Team’s Definition of Done, and any action items that were identified at the Sprint Retrospective. This is a working session for the Development Team and the Product Owner. The Scrum Master is the facilitator, keeping the meeting on track and encouraging the discussion which is an important part of the planning.

Sprint Planning is not a management or executive forum. The Team determines what work they can complete. The Product Owner is there to clarify Backlog order and User Story requirement details.

The Development Team pulls items from the Product Backlog into the Sprint. Then, they break those items down into tasks that are one day or less. These are the Sprint Backlog Items. The objective is for the Development Team to realistically forecast the Stories and tasks that will get them to completion with the Sprint timebox.

The entire Team identifies a Sprint goal. This is the objective of the Sprint and helps the Team focus. A one or two-sentence summary of what work is prioritized in the current sprint, and what should be achieved. this summary may read: “Enable the login mechanism with two-way authentication” The goal should be measurable.

Daily Planning

The final layer of planning in Agile is a huddle that occurs daily. In Scrum, we refer to this as the Daily Scrum. Other methods refer to it as the Daily Stand-Up. Yes, participants are expected to stand up. We stand so that the 15-minute Timebox is respected. This is not a status meeting with the Scrum Master, the Product Owner, or management and it should not turn into one.

It is not an executive or management forum, but an opportunity for Development Team members to talk to each other and make sure they are in sync with each other on what they have completed, what they will focus on today, and anything that is blocking them from getting to done or making progress.

If a Development Team member raises an issue that someone else can help with, make sure the conversation does not derail into the details about this. A Development Team member who can help may say, “Let’s chat after the Scrum, I can help you with that.”

If the Development Team needs time with the Product Owner, they may request that, but they do not have a detailed conversation at the Daily Stand-Up; they ask if the Product Owner can come to the Team room or meet.

The Daily Stand-Up is held at the same time and place every day to reduce complexity. It is a 15-minute meeting at which, each Dev Team member answers the three questions as below.

Daily Stand-Up Questions

• What did I do yesterday to help the Dev Team meet the Sprint goal?
• What will I do today to help the Dev Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Dev Team from meeting the Sprint Goal?

These questions are all directly related to what will help the Development Team. This is a forum for the Development Team to be accountable to themselves and to each other.

Sometimes the Scrum Master and Product Owner will communicate with the Dev Team just after the Daily Stand-Up (sometimes known as the “after meeting” or the “meet aftre”).

For more posts like this follow Agile Digest social Pages or subscribe our newsletter:
Wesbite:   https://agiledigest.com/
Facebook: https://www.facebook.com/agiledigest/
LinkedIn : https://www.linkedin.com/company/agiledigest/
Youtube: https://www.youtube.com/@AgileDigest