Purpose and objective of backlog refinement

Backlog refinement, also known as backlog grooming is an agile practice that involves continuously reviewing, clarifying, and prioritizing the product backlog for upcoming sprints. The primary objective is to maintain a well-organized, prioritized, and actionable product backlog that provides a clear roadmap for the development team. It ensures that the team is ready to select and work on the most valuable items during sprint planning.

Some key aspects are:

1. Breaking down user stories
2. Prioritize and order based on value
3. Estimate effort
4. Identify dependencies
5. Refine acceptance criteria

Key users (roles & responsibilities)

• Product Owner: The product owner is responsible for managing the product backlog, prioritizing user stories, and ensuring that they align with the overall product vision and goals. They actively participate in backlog grooming sessions to provide insights, clarify requirements, and guide prioritization decisions.
• Development Team: The development team, comprising developers, testers, and other relevant roles, actively engage in backlog grooming. They contribute their expertise, collaborate in refining and estimating backlog items, and gain a shared understanding of the work to be accomplished.
• Scrum Master: The scrum master facilitates backlog grooming sessions. They help facilitate discussions, resolve conflicts, and ensure that backlog items are well-prepared for upcoming sprints.

Backlog refinement with Easy Agile TeamRhythm

User goal

So that I can set my team up for success when they commence work on a new Planning Interval/Product Increment, as a Product Manager, I want to be able to set up and configure the User Story Map with the hierarchy, epics, and issues and filtered views I need.

Scenario

PI Planning has been completed and the team is about to commence a new product increment. The Product Manager and Scrum Master meet to refine the backlog and set up the User Story Map in preparation for Sprint One planning.

Hierarchy planning

• Configure Hierarchy - set up the hierarchy so that it is able to be displayed on the TeamRhythm User Story Map

Epic level planning

• Use Quick Create to create new epics to group work

• Edit the details of an epic and save changes

• Set the rank/order of epics (drag and drop)

Issue level planning

• Use Quick Create to add a new issue

• Inline edit to change an issue summary

• Use drag and drop to change the position or order of issues

Issue details

• Configure issue card layout to display additional information on issue cards

Filters and Views

• Create a new filter using a component that is specific to the upcoming product increment & share the view with the team

‍

These tips and tricks have come from countless conversations with our customer base on how to make backlog refinement sessions as effective as possible.

#1 Set a goal

We could refine our backlog for hours. Doing so inhibits us from spending time delivering value to our customers. To ensure backlog refinement is effective and valuable, we need to set a goal for our refinement sessions and share it with the team.

The goal should be centred around the backlog items that are either contributing to the value you're currently developing for customers, or the value that you will next be looking to deliver to your customers.

As a team, we should also have an agreement on what "refined" looks like and what level of detail is appropriate when refining backlog items.

Tangible ways we can do the above is to:

• Share an example of what 'good' looks for a refined story on the backlog so the team have a shared understanding of what level of detail to go into when in refinement sessions
• Agree on the structure/level of detail for different kinds of work items
• Identify subject matter experts for different work items to speed up refinement and have them share learnings across the team

#2 Keep refinement contained to a small group

Scrum Masters and Product Owners should lead backlog refinement sessions.

At the very minimum the Tech Lead should be present in these sessions to provide context into feasibility, complexity, dependencies and high level estimates.

Where appropriate, there should also be at least a few stakeholders present. These stakeholders need to have relevance to the context of work or be the subject matter expert to the sprint goals, otherwise the value they're providing is questionable.

#3 Meet frequently

Anything hard should be done regularly to build the muscle and resilience across the team.

Generally, holding a few, shorter backlog refinement sessions leading up to sprint planning is more effective than a single big bang session.

‍

Writing good user stories

For many software development teams striving towards agile, the idea of writing user stories can seem like another “thing” agile piles on top of their already busy workloads. We hear you, we’re busy too!

A user story helps agile software development teams capture simplified, high-level descriptions of a user’s requirements written from that end user’s perspective. A user story is not a contextless feature, written in “dev” speak.

So how do we write user stories? Better yet, how do we write good ones?

A user story, much like a persona, adds context to your work and in turn value.

The fact is, it’s easy to get buried in a contextless, feature developing cycle. The objective becomes more about clearing your way through a laundry list backlog, than it is about building solutions that add value to your customers. Your human customers. User stories bring that context and perspective into the development cycle.

Here is the equation for writing a user story:

Writing acceptance criteria

User stories allow teams to have one hand on the needs, wants and values of their customers, and another, on the activities they need to accomplish to provide that value.

The link pairing these two things together, is acceptance criteria.

Acceptance Criteria or ‘conditions of satisfaction’, provide a detailed scope of a user’s requirements. They help the team to understand the value of the story and set expectations as to when a team should consider something done.

Related resources

• Download our guide to writing good user stories and acceptance criteria, including a user story checklist

The importance of customer personas to story mapping

How many times can you say you've worked on a user story without really knowing who that user is? Could you confidently share their interest, motivations, communication styles?

When building out our User Story Map we need to know and understand - 'who are our users'? By creating customer personas, we have a better idea of what our customers need or want from our product, their goals and objectives for using it and how they will engage with it.

A sharper and shared understanding of your customer across your team means you can more readily identify and prioritise what will provide most value to your customer.

In this video, Sean Blake from the Easy Agile team talks about how to build your customer persona.

Creating customer personas is a foundation for other agile practices, like user story mapping. It keeps the customer front of mind, providing a 'face' to the user story, creating buy-in and empathy.

‍

Sprints and Versions

The ability to split the story map by sprints or versions allows stakeholders to track progress at a glance and ensure over-commitment is prevented.

When a Scrum Team first opens their User Story Map, they will see it sliced horizontally by Sprint Swimlanes, pulled directly from their Agile Board. The order of the Sprints on the Story Map reflects the order of the Sprints on the Team's backlog.

Sprint swimlanes

When a Kanban Team first opens their User Story Map, they will see it sliced horizontally by Version Swimlanes pulled directly from their Releases Page in Jira. Versions are ordered by their Release date on the Story Map.

Version swimlanes

Creating new Sprints on the Story Map

From the drop down menu in the top right-hand corner, ensure 'Sprint swimlanes' are selected.

To create a new sprint, scroll to the bottom of the story map and click the 'Add Sprint' Button. This will pop the 'Create Sprint' dialogue box. Enter your new Sprint's name and hit 'Submit'.

Note: you must have either Board Administrator or Manage Sprints permission in order to create Sprints on the Story Map.

How to create new Versions

While in the 'Version swimlanes' view of the story map, scroll to the bottom of the story map and click the 'Add Version' button to pop the 'Create Version' dialogue. Enter your Version's name and click 'Submit'.

Note: you must have Project Administrator permissions in order to create Versions on the Story Map.

Sequencing work into Sprints and Versions

Sprints and Versions will appear in chronological order and will be pulled directly from the corresponding Agile Board or Releases Page in Jira.

It's very easy to prioritise work on the Story Map using a simple drag and drop:

↔️ Reorder epics along with their stories with a simple drag and drop.
↕️ Repriortise issues within or across Sprints or Versions.

How to start a Sprint on the Story Map

If there are no Active Sprints, Easy Agile User Story Maps will give you the option to Start the Sprint at the top of your Story Map.

To start a Sprint, click on the blue 'Start Sprint' button at the to pof the Sprint Swimlane. Here, you can edit your Sprint name, add a Start/End date for your Sprint and enter the Sprint goals. Click 'Start Sprint.'

Your Sprint is now active in Jira:

How to complete a Sprint on the Story Map

Active sprints can be completed from the Story Map. To complete an Active Sprint, click on the blue Complete Sprint button at the end of the Active Sprint swimlane.

You will now see an overview of the status of the issues in your Sprint. Under the 'move to' heading, select where incomplete issues should be moved to, then click Complete Sprint.

Why is estimation so important?

How to view Epic, Sprint or Version Statistics

View how your team is tracking by hovering over the 'not started', 'in progress' or 'done' indicators on the far right of your story map. Similarly you can hover over the epic estimate lozenge to reveal how the issues linked to that epic are progressing.

If you want a contextual view of your sprints or versions that allows stakeholders to track progress at a glance and ensure over-commitment is prevented, try Easy Agile TeamRhythm. The highly-visual story map format transforms the flat Jira backlog into a meaningful picture of work, making it easier to plan sprints and versions.

‍

Purpose and objective of PI Planning

The purpose of PI planning is to bring together multiple Agile teams working within a program or large project to align their efforts, synchronize their plans, and establish a shared understanding of the upcoming Program Increment. It is collaborative and structured and the aim is to set the direction and priorities.

Key users (roles & responsibilities)

• Release Train Engineer (RTE): The chief facilitator for the Agile Release Train (ART), they coordinate and facilitate the PI Planning event. The RTE collaborates with Product Management, Scrum Masters, and other stakeholders to ensure a successful planning event and to address any impediments or issues that may arise.
• Product Manager: Define and prioritize the program's features, user stories, and objectives. Working closely with stakeholders and customers to understand their needs and ensure that the product vision is effectively communicated to the Agile teams.
• Product Owners (POs): Collaborate with stakeholders, gather requirements, and maintain the team's backlog. Actively participate in backlog refinement, estimation, and commitment during PI Planning.
• Scrum Masters: Facilitate Agile team discussions, promoting collaboration and considering team perspectives in the planning process.
• Agile Teams: Responsible for delivering committed features and stories, actively participating in PI Planning, estimating work, identifying dependencies, and aligning plans with other teams.
• Business Owners/Stakeholders: Represent organization and stakeholder interests, providing input, clarifying priorities, and aligning work with the overall business strategy during PI Planning.

Facilitating PI Planning with Easy Agile Programs

User goal

As a Release Train Engineer (RTE) my goal during the PI Planning event is to guide and support the Agile teams, stakeholders, and Product Management in collaboratively planning and aligning their work for the program increment, ensuring clear objectives, effective communication, and commitments for successful execution.

Scenario

The PI Planning event is scheduled for a large-scale software development program. As the RTE, I need to ensure that all key parts of the agenda are met including: sharing business context and the product vision, team breakout sessions, and being able to review and adjust plans.

Set higher level priorities and business initiatives

• Create and schedule third level issues

• Create milestones

• Create and schedule issues onto the program roadmap

Team breakout sessions

• Schedule issues from the backlog

• Quick create issues

• Estimate issues and set sprint capacity

• Create objectives

Review and adjust plans (ART level)

• Manage and address dependencies and risks (can be done on the program board and the team planning board)

‍

What is a User Story Map?

A story map is a visual representation of the journey a customer takes with a product, including activities and tasks they complete. This understanding enables teams to focus development on providing the most value to customers and their desired outcomes.

It provides context for teams by answering the following questions:

• Why are we building this?
• Who are we building this for?
• What value will it provide them?
• When do we expect to deliver this?

You may have encountered or done Story Mapping using sticky notes on a whiteboard. Easy Agile User Story Maps enables your team to build a story map digitally and host a story mapping session remotely. We'll dive deeper into that in later modules.

New to User Story Maps?

Used to working with a flat backlog and want to know the difference between that and a Story Map? Not sure what to expect from your first Story Mapping session?

Check out this video where Teagan Harbridge, Head of Product here at Easy Agile explains.

The Anatomy of a User Story Map

A User Story Map has a basic anatomy which brings the customer journey to life as well as the work that supports each of the steps in that journey.

The Epic 'Backbone'

At the top of your story map is the 'backbone' of your product represented by epics. It represents your products' core functionality or essential capabilities.

Each epic within the backbone represents high level activities or actions a user would take with your product. These activities should be ordered in the chronological order of how a user would interact with the product, showing the user journey from the beginning to end.

Example:

The journey a customer would take to watch a movie on the Apple TV:

User Stories

Below each activity on the backbone we create user stories which flesh out the customer story. Sitting beneath allocated Epics/user activities, these stories represent situations/sceenarios a user may encounter on the way.

These stories are ordered by value to the user.

Value may be identified through conversations with users, analytics on usage patterns, or another form of insight appropriate for your product.

To continue with the Apple TV example, the user stories that would sit beneath 'select movie' may be:

• free text search
• browse by genre
• browse by recent addtion
• browse by most popular
• browse by most popular by genre
• browse by recent addition by genre

Sprint / Version Swimlanes

The story map is split into Sprints or Versions which visually represent what is in and out of each release. We'll discuss the process involved in sequencing work into swimlanes, but essentially it's important to remember that the user stories encapsulated in a swimlane reflect the work that needs to be done in that release.

User Story Map breakdown

If you want to get started with user story mapping today in Jira, try Easy Agile TeamRhythm. The highly-visual story map format transforms the flat Jira backlog into a meaningful picture of work, making it easier to manage your backlog and plan sprints or versions.

‍

A Birdseye view of your Backlog

This is an 'unfiltered' User Story Map view for a Banking App.

This view allows us to see all the issues and Epics in a team's Agile Board in Jira.

The backlog icon in the top right hand corner of the page, displays all of the issues that are not associated with an Epic in a team's Agile Board.

Opening this panel, allows us to see a view of all of the issues associated with a team's Agile Board (whether they have been linked to an Epic or not).

Break Down Large Pieces of Work

Sometimes, a user story is too large to complete as one task. Breaking stories down into smaller pieces is simple with the 'quick create' feature.

To create new issues on the User Story Map, hover over the space you wish to create a new issue. Click on the [+] button.

Split your Backlog into Sprints or Versions

The User Story Map can be sliced horizontally by swimlanes. Depending on whether you’re using a Scrum or Kanban Board, these horizontal slices can be changed to show the Sprints from your Jira backlog, or Versions from your Releases page in Jira.

I: Prioritising the Backlog using the User Story Map

Stories are prioritised by a range of value metrics, whether that be to the user or based on business value.

We can prioritise issues on the User Story Map in two ways:

Drag and Drop

Quick Actions Menu

II: Prioritising the Backlog using the User Story Map

We can also prioritise issues from our team's Agile Board that are not linked to Epics in the 'Issues without Epics' panel.

These issues should also be prioritised by value.

Simply drag and drop these issues either inside the 'Issues without Epics' panel, or across onto the User Story Map to link them to an Epic and prioritise them within a Sprint or Version.

Refining the Summary and Estimate of Issues

The ability to inline edit the estimate and summary of an issue is simple on the User Story Map. Simply click on the summary or estimate and begin to type.

Adding more context to your issues

Add more context or requirements to your issues during your refinement session by popping the issue view by clicking on any issue key.

‍

‍

Purpose and objective of managing and addressing dependencies

To ensure alignment and unblock teams to successfully deliver a project, teams must be able to manage and address dependencies. By surfacing and visualising dependencies, you are able to quickly understand and communicate what teams are working towards together and where their work is dependent on each other. You should be able to easily reschedule issues to adjust the plan so teams are set up for success with no scheduling or dependency conflicts and no at risk dependencies

Key users (roles & responsibilities)

When it comes to dependency management and effectively addressing them, it requires a collective effort from the entire team. There is often more than one role responsible for helping a team to remove or mitigate dependencies. Typically the Agile Coach, Scrum Master ad Release Train Engineer (RTE) are the agents in unblocking the teams and keeping them on track.

• Agile coach: identifies dependencies and reveals areas where communication and collaboration need improvement. An Agile coach can facilitate effective communication and coordination to unblock teams.
• Scrum master: Works with the teams to mitigate dependencies to ensure a timely and successful delivery.
• Release Train Engineer (RTE): identifies dependencies that can impact the overall flow and efficiency of work.

Managing and addressing dependencies with Easy Agile Programs

User goal

I am an agile coach, scrum master, or Release Train Engineer and during a coach or ART sync, I need to be able to easily understand progress, dependencies, risks or other blockers that may impact on execution on what’s committed for the current PI.

Scenario

I am a Scrum Master and the development team has flagged they are currently blocked, I need to easily and quickly filter the team planning board to identify and address the at risk or conflicting dependencies to unblock the team

View dependencies (Program Board and/or team planning board)

• Filter by dependency type

Manage dependencies (issue/issue within a team)

• Reschedule

‍

Recent update to Planning Poker functionality - 25th September 2023

Users can now use a link button to copy the calculated story points to that issue's story points field (if it exists). This capability currently only exists for certain board types and the story points field must be present in the project's issue viewer.

Please consult the known issues section at the bottom of this page for more details.

‍

Use case

The purpose of this planning poker action panel is to provide a means to collect a numerical estimate of effort from anyone viewing the ticket, and to provide an average calculation of the estimates provided so far.

What planning poker does today

The planning poker feature allows any logged in user viewing the ticket to cast their vote with regards to the effort required to get the ticket done. The vote cast can be any integer greater than or equal to zero.

A user can re-cast their vote as many times as they like - any previously entered value will be overwritten.

The planning poker panel will show the avatars of everyone who has voted, with their votes initially hidden.

Clicking on the “show votes” toggle button will unhide all the votes and provide a calculation of the numerical average. There is no restriction on how often or how many times the “show votes” toggle button can be clicked.

There is no restriction on when a vote can be cast ie. there is no concept of a planning poker session needing to be started before voting can occur. Teams are free to decide how they will use the planning poker panel i.e. in a dedicated session or asynchronously.

How to use planning poker

The asynchronous approach

Users can leave their estimate on how much effort a particular issue will take at any time they choose. Easy Agile recommends this approach should be taken for the issues that are straightforward and just-do-its. These issues would have been previously debated or already broken down into their smallest possible slices.

A scrum master may choose to review view the submitted estimates at any time and use that as a basis for their accepted story point estimate.

The structured estimation session

A structured estimation session is best used when:

• the issue is new and may not be widely understood by the team yet;
• estimates provided so far are too big or show a wide spread of values.

The session would provide opportunity for the team to discuss the issue and ask clarifying questions before submitting their revised estimate.

Combining the two approaches

1. Shortlist the issues the team would consider taking on in an upcoming sprint
2. Allow the team to submit estimates that they believe are straightforward and just do its in their own time. This could be a couple of days before the next estimation session. The tech lead can autonomously review the issues that are being estimated to see if there is general agreement with regards to effort.
3. Issues that have general consensus with their story points can be considered “done” and can be put aside during the scheduled estimation session.
4. Issues that are contentious with either extremely large or a wide variance of estimated effort can be discussed during the estimation session where the team is in attendance.

Please submit your planning poker related feedback here.

What planning poker doesn't do (yet)

Current limitations of the planning poker panel include:

• There is no access/permission check on who is allowed to cast a vote
• There is no access/permission check on who is allowed to show/hide cast votes
• There is no functionality provided to manage a planning poker estimation session
• There is no way for a user to remove their vote once it is cast
• There is no ability to configure how votes can be cast e.g. t-shirt sizing, Fibonacci sequence
• The average calculated is a basic mathematical average calculation rounded to the nearest integer
• There is no support for a shared session/view for planning poker estimation interactions i.e. all users will need to click from issue to issue themselves

Known issues around "Copy to issue's Story Points" functionality

Issue #1

Click on the message directly to see more detail about why the message might not be updating.

Issue #2

This functionality requires the story points field to be visible in the Jira issue viewer and be editable by your user.

Recommended action is to speak to your Jira or project administrator to check these settings.

Issue #3

This issue appears for issue types that don’t support estimation tracking, such as epics or higher level issue types. This typically occurs on company managed projects, however this will depend on your issue configuration.

Recommended action is to speak to your Jira or project administrator to verify your issue configuration.

Issue #4

This is the default error for Atlassian Jira API errors.

Recommended action is to speak to your Jira or project administrator to validate that the project and issue configurations support story point estimation.

Issue #5

Currently the “Copy to story points” function is only supported on Scrum only boards (can be either team or company managed).

Recommended action is to switch board types if possible, or manually enter the value into the issue’s story points field.

Issue #6

This feature is not supported within Kanban projects, as Kanban frameworks generally do not support the idea of estimation.

Recommended action is to manually set the story points field if it is being used.

‍

‍

Purpose and objective of PI Planning/quarterly planning

Efficient and effective preparation for the PI Planning event is essential for achieving success. The purpose of Pre-PI planning is to establish a shared understanding of the business goals, objectives, product vision, milestones and priorities, and to create a cohesive plan for successful execution. A Program Manager or a Release Train Engineer in preparation for PI Planning, will need to be clear on who will be involved in the Program to do the work (teams), what the business wants the teams to deliver (objectives and features), and any external deadlines or events that may impact timings (milestones)

Key users (roles & responsibilities)

• Release Train Engineer (RTE): Coordinates ceremony logistics and tooling, ensuring readiness of business context, product roadmap, vision, and high-priority features for PI Planning.
• Product Managers: Define and prioritize program features, user stories, and objectives, working closely with stakeholders and customers to communicate the product vision to Agile teams.
• Product Owners: Collaborate with Product Managers, provide insights into the program backlog, prioritize user stories, and align program plans with the overall product vision and strategy.
• Business Owners/Stakeholders: Represent the organization's and stakeholders' interests, collaborate with Product Management to define business goals and objectives for the program increment.
• Solution Stakeholders (Solution Management, Solution Train Engineer, Solution Architect/Engineering): Identify architectural dependencies, make decisions supporting program objectives, and play a critical role in preparing technical aspects for PI Planning.

Pre PI Planning with Easy Agile Programs

User goal

In preparing for PI Planning our goal is to ensure that all necessary information, context, and resources are available for a successful and aligned planning session. This includes refining the backlog, aligning priorities, and clarifying the program's objectives to enable Agile teams to plan effectively.

Scenario

A Release Train Engineer (RTE) is tasked with ensuring a smooth and productive PI Planning event by preparing the necessary logistics, and aligning stakeholders by setting higher level priorities and business initiatives.

• Create a new program increment

• Create milestones

• Create and schedule issues onto the program roadmap

• Set higher level priorities and business initiatives, create and schedule third level issues

‍

Retrospectives are an integral part of any agile team's rhythm and are key to building a culture of continuous improvement.

Retrospectives are designed to help teams pause and reflect on what's working well and to spot areas for improvement.

On this page, we'll share 4 of our best practice tips for getting the most out of your retrospectives.

Tip 1: Optimise the time of day and length for maximum engagement

It is commonly known that retrospectives should take place right after the sprint or iteration has ended and prior to the start of the next sprint or iteration.

This ensures that learnings from the prior sprint/iteration are promptly captured and discussed without losing context, and any learnings can be applied to the next sprint/iteration.

The day and time the retrospective occurs is typically a result of calendar tetris as opposed to anything meaningful.

This tip proposes that we take active measures to ensure that we're holding our retrospectives at a time of day that our team feel most engaged and for a length of time that gels with their maximum attention span.

One way to understand what this means for your team is to simply poll them. Send a quick survey or Slack/Teams message to your team asking them:

• what time of day they are most collaborative
• how long they typically stay engaged during a retrospective

Once we understand this, we should change our retrospective meetings to take this onboard immediately. This means:

• scheduling the retrospective for the time of day where most of the team have indicated they are most collaborative
• having the discipline to not go over the allotted time

Product Tip

Easy Agile TeamRhythm Timer

The Retrospective timer helps to manage and track your time while running a retrospective ceremony. You can time box certain parts of the retrospective to make sure you're keeping your retrospective on time and on track.

Learn more about the Timer functionality here

Easy Agile TeamRhythm Focus

The Focus features enables you to view the retrospective board ordered by created date, number of reactions, or creator.

The feature also allows you to filter the retrospective items by categories.

This, along with the timer, ensures you are respecting the teams time and focusing on the most pressing retrospective issues first.

Learn more about the Focus feature here

Tip 2: Experiment with the Retrospective Format

Collaboration tends to decline when ceremonies become too formulaic and predictable. One way to keep engagement high is to experiment with different Retrospective templates.

Product Tip

Easy Agile TeamRhythm Bling

Easy Agile TeamRhythm comes with a number of out of the box templates for your team to start using. You can also customise any of the columns in Retrospectives to start using your own Retrospective templates.

Learn more about TeamRhythm's templates here

Icebreakers are also a great way to inject fun and versatility into your Retrospectives. Icebreakers help your team build empathy for one another and start connecting on a human level.

They are also a great way for facilitators to understand the headspace the team are in before starting a Retrospective so they can assess what level of engagement or energy is needed to bring into the session.

Tip 3: Ensure all voices have the chance to be heard

Ensuring everyone has the opportunity to be heard is an important part of an effective Retrospective. This can be easier said than done, so we wanted to share a few ways you can foster inclusivity in your retrospectives:

Round Robin the Facilitator

The Retrospective is facilitated by a new member of the team each week. The value of doing this, is that different people bring different ice breakers and different relationships within the team which makes different people feel more comfortable sharing with group.

This tactic is also beneficial because it shares the facilitation load amongst the group which means that everyone gets the opportunity to engage at some point, as well as the opportunity to build the facilitation muscle amongst your team.

Pass it on

Pass it on is a technique where the person who has shared their perspective nominates the next person to contribute. This technique is effective because it takes some of the anxiety out of speaking up within a group, by removing the authority from the facilitator and giving it back to the team.

Tip 4: Take Action

In order to be effective, Retrospectives need action items. In other words, how can we turn what we've learnt this sprint/iteration into tangible ways to improve?

It is important for those action items to be captured, assigned an owner and for the team to be clear on when/if they will be actioned or not.

All action items should be followed up on, ideally at the beginning of the next retrospective. Not following up or actioning on retrospective action items is a sure way to disempower the team from ideating ways to continually improve.

Product Tip

Easy Agile TeamRhythm Action Plans

Convert actions in Easy Agile TeamRhythm into Jira tickets and assign, schedule and track their completion alongside the team's work in Jira.

Learn more about creating Action Plans in TeamRhythm here

‍

We know how important the facilitators role is to ensuring an effective retrospective with the team.

With this in mind, we have purpose built a range of features that are designed to assist the facilitator:

• understand the engagement and overall morale of the team
• keep the conversation focused and to time
• ensure the highest voted/most pressing issues are addressed first
• categorise retrospective items into distinct themes so they can understand trends

We're now going to show you where to find this functionality and how to use it.

Team Mood Survey

The Mood Survey is available for each retrospective board to understand the emotional state of the team and identify improvement opportunities to improve team morale.

Each team member can vote on the desired emoji which best expresses their feelings throughout the Scrum sprint / Kanban cycle. The happiness index is calculated by dividing the number of happy (😀 or 🙂) votes by the number of total votes and multiplying the results by 100.

Measuring happiness index can provide an indication of team’s well-being and we recommend using the Mood Survey for each retrospective.

Facilitator Tip

Understanding the team's overall happiness index leading into a retrospective helps you understand what level of energy to bring as a facilitator.

If a team had a low happiness index for a given sprint, you might decide to change up the order of retrospective items you discuss. For example, you might chose to start by acknowledging the difficulty of the sprint and prioritising the discussion around what didn't go so well and what can be improved for next time.

Learn more about the Team Mood Survey here

Timer

The Retrospective timer helps to manage and track your time while running a retrospective ceremony. You can time box certain parts of the retrospective to boost productivity and keep the retrospective on-track.

Facilitator Tip

The goal is to optimise retrospectives for optimal team engagement, not to fill an hour time slot in the calendar. To do this, Poll your team to understand:

• how long they're most engaged for during team meetings
• what time of day they're most engaged in team meetings
• what day of the week they're works best for scheduling team meetings

Once you have this information, use the timer in the retro to respect the team's time and ensure the conversation remains productive, and the most pressing issues or opportunities are being addressed.

Learn more about the Timer functionality here

Categories

You can add categories to retrospective items to identify similar themed items.

Categories allow you to theme up the types of retrospective items your team are raising so you can see where key improvement areas might exist within your team, or across teams.

Learn more about categories here

Focus

The Focus features enables you to view the retrospective board ordered by created date, number of reactions, or creator.

The feature also allows you to filter the retrospective items by categories.

This, along with the timer, ensures you are respecting the teams time and focusing on the most pressing retrospective issues first.

Learn more about the Focus feature here

‍

Purpose and objective of retrospectives

Retrospectives are a staple of many agile processes. The purpose is to encourage reflection, continuous improvement, and team growth. It enables the team to learn from past experiences, adapt their practices, and enhance their collaboration and performance for future sprints or iterations. The team should end the retrospective feeling positive, engaged and empowered to make changes and improvements based on the insights and discussions during the retrospective.

Key users (roles & responsibilities)

• The entire Agile team: anyone who is involved in designing, testing, or building should attend.They contribute their insights, experiences, and suggestions for improvement based on their involvement
• Scrum Master: It is their role to facilitate the retrospective and help the team identify improvement opportunities and prioritize action items.
• Product Owner and Product Manager: While the primary focus of the retrospective is on the development team, the Product Owner and/or manager may also be involved in the retrospective, especially when it comes to discussing collaboration, communication, or any areas where their input can contribute to the team's improvement.

Agile retrospectives with Easy Agile TeamRhythm

User goal

So that we can improve the way we work together, as an agile team we want to share and discuss our thoughts, feedback and learnings from the previous sprint/version, and draw conclusions that we can implement.

Scenario

The team meet for the Sprint 2 retrospective. The Scrum Master uses the timer to provision time for the team to comment and vote on items. The team add comments, up vote and downvote retro items, and then work through their feedback. At the end of the retro, they complete a mood survey.

• Start/stop timer

• Retro item comment added

• Retro up vote clicked

• Retro item category added

• Retro item description edited

• Retro mood changed

Purpose and objective of sprint/version planning

Sprint planning is a crucial activity within the agile framework, specifically in Scrum methodology. It is a collaborative process that allows the development team, scrum master, and product owner to come together and plan the upcoming sprint. The main purpose of sprint planning is to determine which user stories or backlog items will be worked on, discuss the scope and define the sprint goals to establish a shared understanding.

Here are some key aspects:

1. Establishing sprint goals
2. Prioritizing work
3. Breaking down user stories
4. Estimating effort
5. Collaborative decision-making
6. Commitment and accountability

Key users (roles & responsibilities)

• Development team: Responsible for implementing work during the sprint, actively participating in sprint planning by contributing expertise, estimating effort, and breaking down user stories into tasks.
• Scrum Master: Facilitates the sprint planning meeting, ensuring correct process adherence, and removing obstacles to team progress. Guides the team through planning activities.
• Product Owner: Actively engages in sprint planning, providing insights into the product backlog, answering questions, and assisting with user story prioritization. Holds final decision-making authority for sprint content and priorities.

It is important to note that while the development team, scrum master, and product owner are the primary audience for sprint planning, other stakeholders or interested parties may also be involved, depending on the specific project and organizational context.

Sprint planning with Easy Agile TeamRhythm

User goal

As an agile software development team, our goal is to effectively plan the upcoming sprint by considering our capacity and establishing a shared understanding of a common goal.

Scenario

On the first day of Sprint 2, the whole team meet to plan to create their plan.

• Close off Sprint 1

• Set a sprint goal

• Access a view of work on the backlog you can draw from

• Apply a filter to shape what they see on the story map

• Use drag and drop or quick actions to schedule the work into the sprint

• Re-estimate tasks if needed & review estimate totals to assess commitment

• Assign issues to owners for initial work

• Assess and edit the goal if needed

• Start the sprint

A user story map is a visualisation of the journey a customer takes with a product, and includes the activities and tasks they would typically complete.

Building a user story map is typically conducted at the beginning of a Project or Product, and is a collaborative activity involving the team with the sole purpose of creating a shared understanding of who our customers are and how we should focus our development of stories by providing the most value to our customers.

It gives us a quick and visual way to to understand what part of the customer journey each of our user stories impacts.

On this page, we'll share 3 of our best practice tips for running effective User Story Mapping sessions.

Tip 1: Set aside time and break it down

Getting the team and stakeholders together for an extended period of time can often be tricky.

Depending on the scope of your user story mapping session you may want to take a whole day, however, we would recommend breaking it down to two 3 hour sessions over 2 days.

We also recommend starting after lunch on a Monday and concluding by lunch on a Tuesday.

This gives you a night in between sessions which gives your team the space to employ system 2 thinking after the first session, and also gives the team a chance to get lunch together once the session is completed and informally debrief.

Tip 2: Start with Personas

Before we create a user story map, we need to know and understand who are our users?

By creating customer persona’s before we build out our user story maps, we have a better idea of how those users will engage with the product, and their goals/objectives of using it

Most often we’ll be choosing only one persona to focus on for a story mapping session, so we don’t get confused and so we can ensure we’ve covered all the aspects of the solution for that persona.

Product Tip

Easy Agile TeamRhythm x Easy Agile Personas

Easy Agile Personas allows you link stories on your backlog to Persona profiles in the Jira issue view, using the following custom fields:

• Persona
• Persona Importance

Learn more about Easy Agile Personas here

These fields are exposed in the issue view modal so you can assign issues to Personas + story importance without leaving the user story map.

Tip 3: A single facilitator

There should be a single person whose role is purely to facilitate the user story mapping session.

Something we would encourage, is to ask a Product Manager or Product Owner from another team to run the session.

The value of doing this, is that different people bring different ice breakers and different relationships within the team which makes different people feel more comfortable sharing with group.

This tactic is also beneficial because it exposes other team members to not only facilitation as a practice, but also the practice of user story mapping.

‍

Purpose and objective of User Story Mapping

User story mapping is a visualisation and holistic understanding of the journey a customer takes with a product, from beginning to end. It includes all the tasks they’d typically complete as part of that journey. To expand on that, user story mapping takes all your user stories (across all your persona types) and assigns them to epics in the order that delivers the most value to the customer. From there, stories are prioritized and mapped to releases.

Key users (roles & responsibilities)

A team will collaboratively create a story map at the start of a project or product. It might be an entirely new product, or the product manager might want to pursue a new idea or feature as part of an existing product. Any team members responsible for the product experience should be involved.

• Product Owner: Plays a crucial role in user story mapping. They provide insights into the product vision, goals, and user needs.
• Development team: Actively participates in user story mapping, contributing technical expertise and providing input on feature feasibility and implementation.
• Scrum Master: Facilitates the user story mapping session
• Stakeholders: Business representatives, end users, and other relevant parties, may also be involved in user story mapping. Their perspectives and insights help shape the user journey and ensure that the product meets their needs and expectations.
• UX/UI Designers: Contribute their expertise in user experience and interface design. They help visualize the user journey, create user personas, and provide input on the design considerations for each user story.

User Story Mapping with Easy Agile TeamRhythm

User goal

So that I can commence work on a new feature, as a Product Manager, I want to be able to conduct a User Story Mapping exercise that maps the steps a user will take in my product when using this new feature.

Scenario

The addition of a new product feature has raised the need for a User Story Mapping ceremony to outline the steps that a user would take with the new feature.

Hierarchy planning

• Configure Hierarchy - set up the hierarchy so that it is able to be displayed on the TeamRhythm User Story Map

Epic level planning

• Use Quick Create to create new epics to group work

• Edit the details of an epic and save changes

• Set the rank/order of epics (drag and drop)

Issue level planning

• Use Quick Create to add a new issue

• Inline edit to change an issue summary

• Use drag and drop to change the position or order of issues

Issue details

• Configure issue card layout to display additional information on issue cards

Filters and Views

• Create a new filter using a component that is specific to the upcoming product increment & share the view with the team