Professional Documents
Culture Documents
Agilewhitebook Axaemeala V1chapter06 161124143432 PDF
Agilewhitebook Axaemeala V1chapter06 161124143432 PDF
AGILE PLANNING
RELEASE & SPRINT
V1.0
The value of planning with milestones and goals is that they do not intend to change
considerable parts of the product even if the underlying activities do. Keeping these milestones
fairly constant gives confidence to the team including the sponsors/stakeholders and saves
constant re-planning.
All these activities are regulated by the idea of a fixed-length event or timebox. Agile uses this very
special concept (Timebox) for all the meetings, and planning is not an exception. This is a
previously agreed period of time during which an individual/team works steadily towards
achieving the goal. The particularity is that rather than allow work to continue until the
goal is reached, and evaluating the time taken, the timebox tactic includes stopping work
when the time limit is reached and evaluating what was accomplished.
Considering the aim is to have quicker feedback from the client, the plan reduces in
significance and planning gains in importance. As many projects in AXA are considerably
complex, they need different levels of planning to be in place. Otherwise, the generic view
may be obstructed. Many of these levels run generally in parallel to minimise blockings and to
facilitate constant learning and synergy of the teams towards a shared goal.
Plan of releases
creates a lower view, which includes the necessary information (risks, possible
spikes, mitigations, etc.) to take a Release to market successfully.
Daily Scrum
organises the work for the current day in a Sprint.
Those are applied as a metaphor to express the idea of the Rolling Wave Planning and give a
guideline of how much effort is required at each stage. The idea is not to dedicate more effort
than is necessary to things that may change or even objectives that could be cancelled. The
first thing to do is to identify where you are in order to know how to proceed.
The easiest way to understand the pyramid it is to read it from bottom (base) to top. The lower
part contains the business goals that are part of the Roadmap and that contain Epics; for
example, “we want our VIP clients to get more benefits than our Standard clients”.
On the second phase, the team takes the Epics, has a conversation and comes up with a
collection of related elements that alone confer a benefit to the user, i.e. “VIP client can access
to discounts”, “VIP Clients have rewards”, etc.
As you see, requirements are set at different levels of granularity to avoid expending effort
to detail aspects and approaches that can change and even disappear.
This initial planning is carried out in a number of workshops where the Product Owner, Key
Users, Stakeholders, Scrum Master and Development Team are present. This is the first
scenario where you start using the Rolling Wave.
Apply the next steps in order to support the Rolling Wave technique:
You can use a User Story Mapping to identify dependencies and sequences of your
product features implementation; you will see the details later on in this chapter.
There are other outcomes or activities that should be expected to be completed at this level:
Know the initial solution approach, estimated cost and any other data required by the
Business Portfolio.
Identify high-level risks (i.e. market risks) and set initial expectations.
Know the people who will be impacted by the product (users, manager, IT, etc.).
Score Business requirements (i.e. using Kano Model, Moscow or any other technique)
Release planning meetings place emphasis exclusively on coming release(s) and make any
other required adjustments to the future in order to represent reality.
Sprint 0 has the following specific: preparing all the foundations for the project. The table
below indicates some of the outcomes:
Other Documents
The Roadmap is generally adjusted during the planning and feedback is given to all the
participants. A Product map is created where everything is organised in different areas, such as
technical aspects, architecture, user interface, etc. This mapping is very important, as it will define
the boundaries of the project.
The Size of the Sprint is also defined in this stage, based on how
frequently feedback is expected from users, the process to upload
code and other factors.
The format for this Workshop and First Sprint are similar to the standard Release Planning
Meeting and Sprints Meeting but the goal instead is to have a solid foundation for the whole
project so some practices can be different.
Going into too many details, as this is usually done during the Sprint Planning Meeting.
Attending the meeting with an unprepared Product Backlog or without fully
understanding the purpose of a Release Planning Meeting.
Getting too many interruptions or doing other activities not related to the
initiative.
Going into long technical discussions.
You do not need to understand the details of each User Story, just concentrate on their key
assumptions (read more about what a User Story is on Chapter 4, Agile Requirements).
Invest more time in the most important things only and go down to details just when
are closer to the development phase.
Make decisions at the right time, when you have the best possible knowledge about the
project, client, product team and technology.
Do not believe in a perfect plan, an initial and detailed written plan makes people
believe that "everything" will be in that way. Progressively refine the plan and adapt over
time.
REMEMBER
Keep the focus of the meeting at all times.
Knowledge of how to estimate is needed.
Product Owner should prepare the Backlog before attending the meeting
BENEFITS
Sets the importance of identifying a Minimum Valuable Product.
Ensures that Stakeholders´ input is thoughtfully considered.
Make sure everyone is aligned and understands what the needs are.
Supports a learning environment.
Help everyone understand what the future product releases will provide and the overall product strategy.
Team Working Agreements and Definition of Ready are available and visible.
I (Product Owner) clearly explain the Release Goal to the team and answer all their
questions.
Scrum Master provides the team’s Velocity.
I (Product Owner) introduce the most important User Stories to the developers.
Developers ask enough questions about the stories to be able to confirm the existing
coarse estimates or provide new ones (this may require the Product Owner to split
some User Stories)
Developers assess the technical risk for each story, classify it with any numeric scale
and run Spikes if information is not of sufficient detail (i.e. Spike).
I (Product Owner) establish a Minimum Viable Product (sufficient features to
satisfy early adopters) and define user stories to be completed in the coming release.
If the Velocity is available, everyone has an idea of how many Sprints are needed to
achieve the release.
Brief retrospective of the session.
It is important to stay focused and not to start unnecessary conversations (a timebox can help to
avoid this). Remember that verbal consensus needs to be reached during the Release Planning
with everyone to check if there is common understanding of all variables and responsibilities to
deal with them.
Open the checklist “Organise a Release Planning” to see how to do this meeting.
Techniques such as Story Mapping can be of a huge help at the time of organising Releases
and the desired features.
Open the Checklist “Using Story Mapping” to know this technique or “Organise a
Sprint Planning Meeting” to see how to do this meeting.
Remove or lower the priority for items that no longer seem important.
Add or promote items that arise or become more important.
Split items into smaller items.
Merge items into larger items
Estimate items.
Check maturity of items and ask why.
For simplicity, this activity can be split in 2 parts, the first one focuses on adding new items,
analysing or splitting Epics and adding new Acceptance Criteria to them. The second part of
the meeting focuses on taking the “closer to development” items and going down into a little
bit more detail. The objective of this phase is to make sure that the User Stories closer to be
implemented meet the Definition of Ready.
1. Data collection.
Key information is for the discussion including:
- All projects Product Backlogs (in the case of more than one).
- Current Sprint progress charts and Sprint Product Backlog.
- Macro calendar with milestones.
- A list with requirements that might not be finished in the current Sprint.
- Changes to be incorporated/dropped.
- Any other important information.
3. Estimation.
An overall quick relative estimation based on T-shirt sizes is done in this stage. If a
request cannot be estimated, the Team usually do it in the coming Sprint Planning meeting
or create a specific analysis task for the next cycle. Dependencies and risks are also
analysed at this stage.
Please refer the Estimation chapter of Agile White Book for further information.
A Pluses and Delta retrospective (or another option if you wish) is finally done in order to
improve the process (check Retrospective Chapter for more information about it).
An Agile planning meeting has many outcomes; the following is the minimum number of items to
be expected:
REMEMBER
Keep the focus of the meeting at all times.
Knowledge of how to estimate is needed.
Product Owner should prepare the Backlog before attending the meeting
BENEFITS
Helps identify a Minimum Valuable Product.
Ensures that Stakeholders´ input is thoughtfully considered.
Make sure everyone is aligned and understands what the needs are.
Supports a learning environment.
Help everyone understand what the future product releases will provide and the overall product strategy.
Attendants
Context
User-story mapping technique helps to run the high-level product planning and release
planning. It helps dependencies and identifies the right order. User-story mapping can be
used for both purposes: defining releases of the product or splitting release scope in
several sprints in the best way.
User Story Mapping is a technique, which provides a more structured approach to Release
Planning. User Story mapping consists of ordering user stories along two independent
dimensions. The "map" arranges user activities along the horizontal axis in rough order of
priority (and time). Down the vertical axis, it represents increasing sophistication of the
implementation.
The main idea is to have an overall vision and easily know the required features for a product
by keeping an eye on maximising the Business Value.
The technique can be applied for the high-level planning of releases for projects with extended
scope. In this case, elements are epics rather than user-stories.
2. Gather information
I welcomed the team, reviewed purpose
and agenda, organizing tools, etc.
Attendants
Context
Product Backlog Refinement is an on-going activity throughout a Scrum project. Which the
team should allocate around 10% of the Sprint time for. These are the activities to do in order
to maintain a proper Backlog and run a refinement session: remove or lower the priority for
items that no longer seem important, add or promote items that arise or become more
important, split items into smaller items, merge items into larger items, estimate items, check
maturity of items and ask why. The idea of a Product Backlog Refinement activity is to
prepare for the upcoming Sprints. The refinement activity gives special attention to preparing
items that are coming closer to implementation.
2. Input collected
3.Requirements Identified
and Categorised
We reviewed purpose and agenda, organizing
tools, etc.
4. Elements estimated
Overall quick relative estimation based
on T-shirt sizes was carried out (the team
initially decided an M size type of work
where new requirements should be
compared).
If some element was not estimated for
some reason, they were noted down and
the task included to be done in the coming
Sprint.
Outputs
Retrospectives
Attendants
Context
The objective of Release Planning is to define the contents of a release or a potential
shippable product increment. It involves identifying the goals for the release,
prioritising and sizing User Stories, and establishing due dates.
For more details – please refer chapter 6 of Agile White Book – Agile Release Planning.
Task Comments
To increase the confidence of what can be delivered, the team creates a plan for how to develop
and deliver the selected product backlog items. The selected product backlog items that are
planned for the sprint form the Sprint Backlog. The Sprint Backlog and the Sprint Goal are
considered the main two outcomes of the Sprint Planning meeting!
Participants in Sprint planning meeting is the whole scrum team which means the Product Owner,
the Development Team and the Scrum Master. If for some reason you think that you need people
with specific knowledge and skill that could help you make better decisions feel free to invite them
as well.
The first part is focused on WHAT product backlog items would be good to complete in the sprint
and will return the most value for your product and your customers.
The second part is focused on HOW to complete the selected product backlog items into valuable
product increment
So, let’s take a look at the activities that need to be followed for an effective and efficient sprint
planning meeting.
Preparations: make sure that the following set of inputs is available in the sprint planning.
It will help and guide the team to make better decisions related to what could be completed
by the end of the sprint.
o A prioritised, appropriately detailed, estimated product backlog where the top items
are marked as “ready” (based on Definition of Ready) to be undertaken by the
development team. Take a look at the chapter of Product Backlog refinement
meetings, where most of these activities should happen there!
o Team capabilities considering public holidays, leaves, availability etc. that might affect
the skills required to complete the work for the sprint (refer to understanding team’s
capacity subchapter). You need that information in order to make a realistic plan and
find ways to mitigate any raised risk.
o An indication from the Product Owner for the sprint goal that needs to be achieved
and will serve as input for further discussions and collaboration with the Development
Team aiming to reach a common and shared sprint goal!
o Product Owner presents the sprint goal for the coming sprint and describes the
desired product backlog items that if completed, the goal will be reached.
o Product Owner and the Development Team collaborate and discuss the suggested
product backlog items that could be taken in coming sprint. Even though the items
should be marked as “ready” (outcome of Product Backlog refinement) it’s an
opportunity to highlight possible risks, review details related to dependencies
acceptance criteria, documentation, models, UX artifacts etc. It’s even possible to
change the prioritisation as/if needed.
o The Development Team based on past performance data, for example their average
velocity, collaborate with Product Owner on the sprint goal. Make sure as
development team to consider your capabilities and highlight any foreseen risks or
known issues!
o The Development Team, the Product Owner (if needed) and any other person that
could share knowledge and experience discuss around possible solutions on the
selected Product Backlog items. Visual thinking and sharing knowledge is vital. Make
technical designs use flip charts and discuss what the functionality will look like is
highly recommended.
o Develop technical models that may be useful to share approaches. It’s a collaborative
activity and make sure to use flip charts and whiteboards to increase understanding
and reach consensus easier. Make photos of them; keep them in your knowledge
repositories for future reference.
o Considering the team’s capacity and the identified tasks, the Development Team is
much more confident to forecast if they can finish (or not) selected backlog items as
outcome of the 1st part of the meeting. If there is more capacity available, renegotiate
with the Product Owner what else could be selected. The final forecast is shared with
the Product Owner.
o The second part outcome should be a Sprint Backlog that contains the forecasted
backlog items and their related tasks. Make sure that your sprint backlog is prioritised
so that that the risk of not reaching the sprint goal is minimized. In addition try upfront
to resolve or find workarounds for any known dependencies, issues and risks that will
affect you reaching the sprint goal.
1. Reserve capacity for the sprint ceremonies (for a two week sprint, almost one full day collectively
for sprint planning, reviews and retrospective is needed).
2. Reserve about 10% of sprint capacity to support the Product Owner in Product Backlog
refinement activities.
3. Reserve some time (based on your previous experience and data) on activities for supporting
issues of current product, maintaining other products or other activities not related with the
current sprint.
4. Reserve scheduled time that team members will be off work or engaged with other activities.
5. Reserve some time (buffer) to handle unforeseen events that may happen during the sprint.
Some items might be larger than estimated or more complex. Again, make use of previous
experience and data.
Now that you know how much time you should reserve, you hopefully have a better view of what
available time you can dedicate to the current sprint!
Scrum Master or Product Owner allocating work to team members during the planning
Team members should decide themselves on which items they should work on based on priorities
set and starting from the highest items! The Development Team should self-organise around their
sprint backlog. This could be quite easy if team members’ skills are fairly balanced. If this is not
possible, and you see that you have bottlenecks that prevent the flow of work during the sprint,
reflect and rethink! What should you change to enable work to flow? What improvements do you
need to consider to make your team a truly cross-functional and self-organised team? What
practices would you consider?
Anti-pattern #2
Product Backlog items discussed for a first time during sprint planning
Sprint Planning meeting requires that the suggested product backlog items are already discussed
during Product Backlog refinement and are aligned with the Definition of Ready. During Sprint
Planning the suggested items will be reviewed in order to resolve any possible misunderstandings.
Seeing for the first time the backlog items during Sprint Planning will result in a low value meeting
and unrealistic plans and commitments. Bring this observation to your next retrospective and find
ways to improve! Reflecting on your meetings’ effectiveness, roles and responsibilities could be a
good start!
Anti-pattern #3
Task splitting is an activity done by the whole team, which means that all team members should be
present and share openly their opinions or suggestions. How could you differently maximise
synergies from prior knowledge and experience? How could you reach consensus on how to work
on that Sprint?
Prioritised Sprint Backlog with common understanding and forecast of Product Backlog
Items to be delivered in the Sprint.
REMEMBER
Sprint Planning is split in two parts. 1st part is about WHAT to do and 2nd part about HOW to do it
The outcome of sprint planning should be a sprint backlog aligned with a shared goal
BENEFITS
Supports a learning environment.
Attendants
Context
Sprint planning - main objective is to transform product backlog items into tasks and
actions, which can be completed by development team during the sprint. The meeting
usually contains of two parts with different goals: (1) Product Owner explains priorities to
the team and clarify outstanding questions, (2) Development Team split backlog-items
into tasks and action items.
For more details – please refer chapter 6 of Agile White Book – Sprint Planning.