Workflow

I was fortunate enough to travel to San Diego for the recent Global SAFe Summit. It was there that the folks from Scaled Agile Inc. unveiled SAFe 5.0 to the audience of 2,100 people from all around the world.

Like many in attendance, I was both excited and overwhelmed with all the changes including the refreshed Big Picture, renewed focus on customers and concepts of Business Agility just to name a few.

After the long flight back to Australia, and having had time to share my learnings with the team, we're super excited about what these changes mean for scaling organizational agility and we wanted to share a few of them here with you.

What's new in SAFe 5.0

1. Introduction of Business Agility

How is this different? Business agility now incorporates the whole business in the move towards value streams rather than individual departments.

2. Refreshed look and feel to the SAFe Big Picture

3. New SAFe Overview

4. SAFe 5.0 'revamps' 2 of the Core Competencies of the Lean Enterprise:

• Agile Product Delivery from DevOps and Release on Demand
• Enterprise Solution Delivery from Business Solutions and Lean Systems Engineering

Plus, Addition of 2 new Core Competencies:

• Organisational Agility
• Continuous Learning Culture

5. A 10th SAFe Principle was announced

NEW: Principle #10 - Organise Around Value

Why are we excited about SAFe 5.0?

It's not the updated Big Picture diagram, or the more approachable and "business friendly" overview that has us excited about SAFe 5.0. What we're more excited about than anything, is the renewed focus on customers - hooray!

While we enjoyed playing a customer version of 'Where's Wally?' in previous SAFe Big Pictures, this renewed focus on customers represents a shift in the level of maturity of organizations adopting SAFe.

They are no longer at a point where "doing" agile is their primary objective. This shift towards customer-centricity embodies what it truly means to be agile, where satisfying the customer is our primary objective.

We've also seen this shift more broadly, as customer/user satisfaction was cited as the #1 success metric for both agile initiatives and individual agile projects in this year's #StateOfAgile report.

How does SAFe 5.0 encourage customer centricity?

The revamped Core Competency of Agile Product Delivery (previously called DevOps and Release on Demand) is what really has us using emojis like ❤️ and has us feeling jazzed.

The DevOps and Release on Demand competency was all about "delivering value to customers" by forming value streams and optimizing continuous delivery pipelines to ship stuff into the hands of customers quickly.

The idea that value to customers = shipping working software more regularly is 💩.

A bad feature is still a bad feature no matter how much faster it lands in the laps of customers. Worse still, a bad feature that your customers don't use, didn't want, or doesn't make them better at their job...... I think you know where I'm going with this.

This revamped Agile Product Delivery competency instead places the focus waaaaaayyyy before anything is actually built - the first order of business should be having a customer-centric mindset by:

• focusing on the customer
• understanding their needs
• thinking and feeling like the customer #bethecustomer
• building a whole product solution
• knowing the customer lifetime value

How do we achieve customer-centricity?

Putting customers at the center of all decisions and incorporating Design Thinking practices into the mix well before we even think about building anything is key to achieving customer-centricity.

This all sounds great, but what does this look like in practice? The diagram below is probably our favourite asset in the entire SAFe catalogue and we think it showcases practical examples of Design Thinking in practice:

Our personal favourites

Personas 💁🏽‍♀️

It might seem trivial at first, to come together as a team, creating what seem like fake dating profiles for your customers.

However, this exercise sets the foundation for other agile practices down the track, and its perceived benefits are often undervalued.

Teams that have a shared understanding and alignment around the types of people using the solution they are delivering are more likely to succeed.

We want to make sure we're building the right solutions, for the right people, to help solve the right problems at the right time, otherwise we risk the following scenario:

Knowing the customer deeply is no longer the sole responsibility of a (traditional) Sales and Marketing team. Agile practices have called for the development of cross-functional team members to step up and help connect with customers.

Related blog post: how to create personas with your team.

It's no secret as the makers of Easy Agile TeamRhythm that we love user story maps (shameless 🔌).

So what about this agile practice do we love so much that we decided to form a business off the back of it?

The purpose of engaging in this activity is to create a shared understanding of who our customers are, how they interact with our products and how we should focus our development efforts on stories in order to provide our customers with the most value.

In other words, it gives us a way to say, ok I'm working on building this user story, I know who the user I'm building this story for is, and I can understand which part of the customer's journey this will be directly impacting.

We believe this shared understanding is incredibly powerful for both building with empathy and putting our customers at the heart of of all our development decisions. We believe this practice exemplifies what it means to be customer centric, and that's why we ❤️ it.

Verdict

Easy Agile welcomes the big changes introduced in SAFe 5.0, especially calling out customer-centricity, design thinking, and business agility. We can't wait to see how our customers start introducing this to their teams.

If you want to better understand the characteristics of SAFe agile teams, and what leads to the successes and failures. Register now for our upcoming webinar.

Do's and Dont's of Agile Teams with Adaptavist

Tuesday March 8 AEDT

REGISTER NOW

Large organizations use SAFe Agile to improve their operations. When you use this framework, you scale Agile to create a Lean enterprise.

This approach helps meet the challenge of delivering constant value. It also helps to support continuous improvement.

Another benefit of using SAFe® is that you get to plan and apply a predictable workflow schedule. When leaders link strategy with implementation, they increase their performance and productivity.

SAFe stands for scaled agile framework enterprise. You can use this framework to apply agile methodologies, such as Scrum or Kanban, to larger teams. SAFe training and certification courses help leaders plan and implement the philosophy.

In this article, you’ll learn about the benefits SAFe can offer your enterprise and how effective organizers lead and implement SAFe. You’ll also hear about training courses that can help.

Want to empower your team to implement the Scaled Agile Framework (SAFe)?

Try Easy Agile Programs for Jira

Free Trial

Major benefits of implementing SAFe

SAFe values alignment, transparency, quality, and execution. It inspires enterprises to adopt lean-agile thinking across multiple departments or teams. Lean methodology means higher productivity, reduced costs, and improved work quality. By identifying value streams and streamlining work processes as you implement SAFe, you can start to create a Lean enterprise.

💥 Achieve team alignment at scale: Easy Agile Programs product demo 💥

Register

By implementing SAFe, you gain the tools to support lean thinking. You create Scrum teams who understand what the user wants, how to deliver those changes with minimal time waste, and create efficient processes. SAFe will also clarify roles and processes so teams can quickly react to problems.

Many large companies have applied SAFe and report major benefits. One of these benefits is increasing employee satisfaction and productivity by as much as 50%. Then, there’s up to a 75% increase in product quality and time to market.

SAFe methodology teaches you to apply a systems approach to pain points, workflow management, and value streams. A healthy amount of cross-team collaboration can begin. The end goal is enhanced value flow.

The transition to using SAFe can take time and trial and error. Being brave enough to engage on a meaningful level and produce better quality outcomes is part of this new norm.

Beginning to use SAFe: The big picture

Using SAFe in your organization can be a major transition. You’ll need to consider how effective leadership and implementation will help make this transition.

1. Leading SAFe

Leading SAFe means building cross-functional teams and developing workflows that help your team get the most value out of planning. That way, software development teams can quickly respond to customer’s needs.

A solid SAFe leader improves productivity, product quality, and time-to-market.

Other identifiers of quality SAFe leadership include better team member engagement, which helps work better and feel part of a supported and supportive team. The value that individuals bring to the organization then increases.

Leading SAFe course

The Leading SAFe® training course is foundational. You’ll mainly learn about SAFe principles and their practices.With SAFe certification, you learn how to apply and scale the scaled agile framework for Lean and agile development. You’ll also learn how to plan and implement Program Increments (PI).

Once you have this information, you can guide transformation across your organization.

2. Implementing SAFe

To properly implement SAFe, you need to know how to coach agile teams through the SAFe framework and Lean-Agile mindset.

Before you can do this, you need to know how to identify and maximize value streams in work processes. In doing so, you’ll increase team collaboration. By increasing collaboration, you’re better positioned to produce value for product owners.

As you implement SAFe, you’ll constantly develop solutions to organizational problems and understand each person’s role in this framework.

Essentially, you start and sustain long-term change that increases value and profits. You then coach others on how to capture the value and apply SAFe principles in practice to achieve long-lasting change.

Implementing SAFe course

Implementing SAFe® is another foundational course. This training course offers an in-depth look at the SAFe Agile framework. It also teaches you how to apply your learning.

In this course, you’ll learn how to design a SAFe implementation plan, plan for enterprise transformation, introduce and launch Agile Release Trains (ARTs), and encourage the organization to be a lean enterprise. You’ll become a large-scale agile coach who teaches others to see and apply large solutions.

Implementing SAFe is ideal for anyone who wants to know how to lead transformation. It focuses on leading SAFe with remote teams. You get to find out how to create Agile Release Trains (ARTs) and show others how to design ARTs.

More SAFe roles and processes

As you learn how to incorporate SAFe, you’ll need to focus on empowering key team members and focusing on some crucial areas. SAFe training is available for some of these roles and processes.

• The SAFe Advanced Scrum Master coaches Scrum teams as they adopt the agile mindset.
• Lean Portfolio Management helps with cross-team collaboration as you adapt to customer needs.
• The SAFe Release Train Engineer is key for Agile Release Trains. This person works on PI Planning, among other events. This, along with the product manager, is a core position for leading SAFe to get the most out of value streams
• A Certified SAFe Program Consultant (SPC) leads change across the enterprise at all levels by coaching and training team members as they adopt the lean-agile mindset. The SPC also organizes and mentors employees to encourage ongoing engagement.
• You’ll need to empower teams to learn how to be a skilled member of an Agile Release Train.

Are you a Release Train Engineer or Program Manager struggling to effectively manage an agile release train or program?

Register for Easy Agile Programs Product Demo

As a proud Scaled Agile Platform Partner, Easy Agile Programs enables Release Train Engineers and Program Managers to effectively manage programs at a ‘team-of-teams’ level to deliver alignment at scale.

Try Now - Free Trial

More Agilist certification courses include training as a release train engineer and a SAFe Scrum Master. You can also take these two-day to four-day certified SAFe training courses to improve your competencies.

For advice on which certified SAFe courses are best for you, go through these FAQs to boost ongoing improvements in your organization.

SAFe training for better enterprise agility

Adopt SAFe to create a Lean enterprise with large-scale change. It encourages cross-team collaboration, systems thinking, and a lean mindset.

While SAFe can take time to implement, there are resources to help, including SAFe training courses. Choose to focus on team members and processes that can most benefit from extra guidance.

You can also follow the Easy Agile blog, podcast, and learning hub for extensive guidance on agile principles, roles, and tools.

Streamline visibility and provide transparency of your Program

Easy Agile Programs Product Demo

Register Now

Many organizations struggle to manage large-scale projects. SAFe can help.

SAFe gives you the framework and training that you need to make a sustainable change on a large scale. If you want to change on a small team level, department level, or across the enterprise, SAFe shows you how.

There are many benefits to implementing SAFe. But what exactly is it, and how can you use SAFe to help create a lean enterprise?

Want to empower your team to implement the Scaled Agile Framework (SAFe)?

Try Easy Agile Programs

JOIN A DEMO

SAFe background

SAFe is the acronym for “Scaled Agile Framework.” As agile focuses on small-scale continuous improvement, SAFe uses its philosophy at an enterprise level.

SAFe increases business agility, resulting in flexible and responsive teams for large organizations. SAFe uses its own set of values along with Lean-Agile principles.

This agile framework started when software systems expert Dean Leffingwell became frustrated with traditional work processes in the software industry. He developed the SAFe method to help change work processes that reaped results.

You can use this framework to instill a Lean-Agile mindset on a large scale. It focuses on constant improvements. As a result, enterprises improve work performance and productivity.

You can access training through Scaled Agile Inc. to scale work and improve performance in your enterprise.

Implementing SAFe at the team, program level, or enterprise is completely doable.

Try Easy Agile Programs for Jira

SAFe values

The Scaled Agile Framework uses four core values:

1. Alignment of business decisions with the business vision, strategy, implementation and goals on a small to large scale.
2. Built-in quality to produce desirable outcomes that create success.
3. Transparency: Good decisions can only be made when comprehensive information is available.
4. Program execution that links back to strategy and vision

By applying these values, teams and organizations increase engagement by making it clear what they expect of agile team behaviors and actions.

When everyone works together and understands their responsibilities, the chance of success increases dramatically. SAFe encourages openness and engagement in meeting individual and team responsibilities. So, if an individual or team hits a roadblock, they communicate to find joint solutions to problems.

At scale, organizations use Lean-Agile methodology to:

• Drive the on-time delivery of software development products
• Support quality product deliverables
• Increase stakeholder engagement and satisfaction
• Streamline performance based on regular, predictable schedules

💥 Achieve team alignment at scale: Easy Agile Programs product demo 💥

JOIN A DEMO

What is agile?

SAFe applies the agile methodology to larger teams. So, let's cover what agile means.

Agile methodology focuses on flexibility, collaboration, and value delivery. It means constantly adapting, or iterating, a product based on changing user and stakeholder needs. Agile teams rapidly respond to change and quickly adapt, whether they use Scrum or Kanban.

Every iteration has a set timebox. Team members use these increments to support streamlined workflows. They create, test, and deliver outcomes that work better than traditional work processes.

What is Lean?

Lean methodology also plays a role in SAFe.

The Lean method has its roots in the auto industry. Ford motors, Toyota expanded on Ford's methodology to further minimize waste and deliver value. Now, Lean has a more comprehensive set of principles with practical applications.

Lean highlights the importance of reviewing value streams to improve efficiency and create more customer value.

When you use Lean principles, teams create more value, higher performance, and increased productivity. In other words, Lean supports business agility.

SAFe incorporates this Lean method of work. So, you can also apply SAFe to lean portfolio management (LPM) and many other areas of the organization.

SAFe Agile principles

The SAFe Agile framework also focuses on 10 SAFe principles. These principles help link performance, quality, and profits.

1. “Take an economic view.”
2. “Apply systems thinking.”
3. “Assume variability; preserve options.” This means no one solution is correct, so teams should keep an open mind when discussing work approaches.
4. “Build rapidly in increments to hasten learning cycles.”
5. “Create milestones on objective analysis of working systems.”
6. “Envision and restrict WIP, limit work batch sizes, and control queue lengths.” Any stoppages and problems lengthen the time to market, increase the use of scarce resources and reduce potential profits. In short, “time is money.”
7. “Apply cadence, synchronize with cross-domain planning.”
8. Encourage the innate motivation of knowledge within Scrum teams
9. Spread the decision-making process
10. Organize goals and work around the value that it creates

What is SAFe’s big picture?

If you’re having a tough time trying to visualize SAFe, let’s look at the big picture. Whereas the typical agile team is smale, SAFe offers a way to scale agile methodologies to larger organizations. It focuses on cross-team collaboration and motivates everyone to adopt a Lean mindset.

This means streamlined work processes and a clearer understanding of which processes create value. It also encourages larger teams to constantly adapt and improve.

The framework shows how strategic planning can transform into practical work execution. Agile teams use the Agile Release Train (ART) to collaborate at each level of work to make this happen. SAFe also offers training to become a Release Train Engineer to support change.

At each level, the framework also indicates the SAFe principles that teams must use. By using these principles, they achieve value creation via coordination and a flexible workflow.

Create and visualise dependences within a single team or between teams

Focused Team Planning

Join a Easy Agile Programs Product Demo

The benefits of implementing SAFe

Leaders and employees can see the SAFe roadmap and workflow. They can also see the large-scale impact on business agility.

Some of the benefits of implementing SAFe include:

• Improving systems thinking across the organization
• Improving value streams and quality outcomes
• Increasing productivity
• Developing team environments through lean thinking
• Decreasing time-to-market
• Creating specific methods to achieve goals
• Generating transparency that clarifies roles, responsibilities, and action
• Removing silos and aligning smaller teams with the greater whole of the organization
• Increasing business agility to meet overall organizational goals

SAFe Agile certification

You can take advantage of certified SAFe Agile training courses to upskill your agile teams. Scaled Agile Inc. offers various training courses to manage Agile transformation.

SAFe training courses can help you implement SAFe methodology, lead SAFe teams as a SAFe Scrum Master, and manage Lean portfolios in SAFe.

SAFe + Jira = Success

Combine SAFe and Jira, and you have a comprehensive framework for success. After starting with SAFe, enterprises report significant, quantifiable improvements in implementing strategies.

Check out Easy Agile Programs for Jira. This app helps align teams at scale with its Program Roadmap. Viewing dependencies and other milestones at the ART level. Try it for free.

Try Easy Agile Programs for Jira

Get ready for remote user story mapping.

Whether you've done user story mapping before (in person) or you're new to user story mapping, there's a very good chance that you'll need to do remote user story mapping for the first time in 2020.

Even before the pandemic, 4.7 million people in the US worked remote, and an estimated 31% of US workers employed in March 2020 were working from home by April 2020.

And after lockdown ends, it’s likely we’ll see permanent changes to the way we work. Surveys show that 80% of employees are keen to work from home at least some of the time. Plus, more organizations are realizing that offering flexible, remote work options can lead to better work-life balance for employees, lower overheads, lower environmental impacts, and improved productivity.

...which is all to say that remote user story mapping is about to be the norm.

So, what do you need to know before you run your first online user story mapping event? Let's go through 8 things you should consider for successful remote user story mapping.

1. Get the basics right

First thing's first: you need your basics sorted. Make sure your team understands what user story mapping is, why user story mapping is important, and how to do it.

This will help get them onboard - which is critical, because you'll need them to commit two full days to the process.

If anyone on your team is new to user story mapping, send them to our user story mapping ultimate guide. It's got everything they need to know 👌

2. Set your agenda

User story mapping should be a scheduled event. You should know what's happening and when to make sure that your team stays on schedule and completes all the steps required to produce a finished story map. Here's a fairly standard agenda:

Knowing your agenda is especially important for remote story mapping, because it's a lot easier to veer off track when people aren't physically in the room.

Sally might head to the kitchen for a long lunch and miss the most important bit. Or Bob might need to coordinate his schedule so that his partner can mind the kids for a solid hour or so while he's involved in estimating the work.

Setting the agenda ahead of time will also help your team start thinking about the session and user stories before the event. That way, they’ll feel more prepared and ready to participate in discussions.

By the way, if you’re not familiar with all the items in the above agenda, we talk more about the specific steps and how to do user story mapping in our ultimate guide to user story mapping.

3. Plan your session

When are you going to hold your live online user story mapping session? Most teams need a full two days to work through all the steps, so you'll need to find two days (ideally in a row) when everyone is available.

If your team is located across multiple time zones, you'll also need to consider what times give you the best crossover so that team members aren't working at 2 am (unless they want to).

4. Decide on who

Remote user story mapping could present you with a bit of a conundrum. Unlike in-person events where you're limited on space, you could technically have unlimited people chime into your virtual session. But you definitely don't want that - too many people will make you inefficient (and they could use their time to add value to your business in other ways).

It’s a good idea to cap your numbers at around 12 people. Include team members and stakeholders across multiple departments, along with your product manager, UX designer, and developers.

Also decide who is going to lead the session and who will be responsible for creating the story map.

The good news is that online user story mapping makes it easy to record sessions - you'll have a digital record of your conference calls and your story mapping board. So anyone who's curious can easily catch up on the highlights once your event is over.

5. Make some rules

Working and collaborating remotely can feel a bit like the wild, wild west - especially the first few weeks or months. Everyone's still figuring out how to make this thing work - and how to get things done effectively in a new environment.

We've all been to conference calls where somebody didn't know proper etiquette or their audio/video ended up distracting other attendees.

So, with that in mind, here are some rules you might like to share ahead of your remote user story mapping session to make it a little less chaotic and a lot more productive:

• Don’t be late
• Put your camera on
• Save your food for a designated break
• Don’t take your device for a walk
• Close your door, if you can
• Stay focused on the task (no checking emails!)
• One person talks at a time
• Wait until everyone has had a chance to provide input before moving on
• If you’re not talking or participating in the conversion, mute yourself (to avoid interference or background noise that could stop people from focusing)

Of course, be realistic. Your team members are likely working from home in less-than-ideal circumstances, whether they're quarantined with family members, stuck at home with a sick child, or dealing with a bad-mannered house dog.

There will be noise and disruptions - and despite their best efforts, someone will be late. As long as people do their best to hit the mute button at the right time and consider others, your session should run smoothly.

6. Get your tech ready

Previously, you might have been able to show up to a user story mapping session with just your brainy self and a pen 🧠🖊️ You'll still need your brain for remote user story mapping, but you can ditch the pen.

Instead, you'll need to make sure you and your team have access to the technology they need to participate and collaborate online. Things like:

• Zoom, Google Hangouts, or Skype access - Everyone should have their account ready to go, along with some experience using the platform
• Slack or Microsoft Teams - Set up real-time chat for when you’re not in a video conferencing session
• Headphones & Microphone - These should be working well and tested ahead of time
• Webcam - While not strictly necessary, a webcam will help you replicate the feeling of being in the room together
• Internet - Ask your team to test their connection and make sure it's reliable - and ideally, have at least one backup option (like a local cafe, friend's house, or mobile hotspotting)

The right technology will allow you to adapt the user story mapping process to work for your remote team.

7. Get user story mapping software

A physical user story mapping session usually involves a long sheet of paper or cardboard, with hundreds of tiny post-it notes for each story and backbone item, and string to show cut lines.

The good news is, if you're doing remote user story mapping, you won't need to clear out your nearest stationery supply store 🎉 But you will need to equip yourself with some digital tools to replicate the physical story mapping board online.

There are a few user story mapping tools on the market, but we're partial to Easy Agile User Story Maps. It plugs straight into your existing Jira workspace, allowing you to:

• Visually map your customer journey
• Assign stories to epics
• Prioritize and sequence stories
• Arrange stories into sprint and version swimlanes
• Add story point estimates

It’s just like physical user story mapping, but done digitally inside of Jira. That makes it perfect for running a remote user story mapping session.

Okay, so we may be a little biased, but these people aren't:

Want to give it a spin for your upcoming remote user story mapping session? Sign up for our free 30-day trial to see the benefits for you and your team. We’re confident you’ll love what you find!

Try it now

8. Integrate your workflow

Last but not least, make sure that your remote user story mapping session integrates with your workflow

Good news! If you use a digital user story mapping tool (like Easy Agile's), you'll find it much easier to integrate your story map into your workflow. Once your user story mapping session is finished, your user stories are already set up in Jira, and organized into sprints or versions so that your team knows exactly what they need to work on next.

(Although they might want to take a day or two to ease back into it...😴)

Set yourself up for success!

With the right preparation and tools, you'll set yourself up for a relatively smooth remote user story mapping session. And after that? You'll be set to do your future story mapping events in a more streamlined, digital way, whether you're required to work remotely, collaborate with a distributed team, or work from the office.

And based on the way work is changing in 2020 (and beyond), that's a very good skill to have.

Agile retrospectives are a time to reflect on the sprint before. During this time, the Scrum team decides on the agile retrospective template to use during retrospective meetings. A sprint retrospective template provides a structure for retrospective meetings. These retrospective templates guide agile teams in analyzing their previous sprint.

What is an agile retrospective?

Teams use agile retrospective meetings to improve the next sprint. As the team members move through the product life cycle, they gain new learning after each sprint retrospective, which they apply to the next sprint.

The focus of the sprint retrospective meeting

Sprint retrospective meetings ask four questions, as listed below. The agile team places these four questions in the four quadrants of their retrospective template. (Note: Team members can use a whiteboard or sticky notes to set up their meetings. Or they can use Jira software to facilitate remote team meetings in real-time.)

Co-located agile teams can also use whiteboards and sticky notes to do an agile retro. But for remote teams, agile retrospective template software allows all team members to participate in sprint meetings.

Here are the four question areas for discussion:

• What went as planned?
• Where could the team have made improvements?
• What should team members do in the next sprint?
• What confuses the team?

1. What went as planned?

The agile retrospective requires in-depth analysis. Team members can chat about what they enjoyed, which methodologies worked for them, and what agile ideas are worth taking into the next sprint.

Typical questions that agile teams ask in this first stage include:

• What were team members happy with?
• What actions delivered positive results?
• What processes or actions should the agile team continue with?
• Should anyone receive a special thanks for their contribution?

2. How could the team have improved?

Stakeholders examine where they went wrong and try to find the root cause of the issues. Brainstorming involves what they could have tried previously, where improvements are needed, and what processes or actions they can test in the next sprint.

Here are some ways to make this question more concrete:

• What has the team previously not tried that might work?
• What is one new thing that we could attempt?
• What new tactics or actions can we test next?

3. What should team members do in the next sprint?

In this part of the template, the team explores new ideas for how to improve their follow-up approach. New ideas can be risky, so the Scrum team should carefully consider opportunities for improvement. The idea in this questioning phase is to clarify problem areas, where value was not produced, and what was puzzling in the previous sprint.

In this round, the team should discuss:

• What didn’t work?
• What did the team do that did not produce value?
• Which areas specifically require improvements?
• What did not go as anticipated?
• What issues in the previous sprint are confusing?

4. What still confuses the team?

In this section, the team should focus on areas that weren’t as effective or did not go as anticipated and what areas need improving. Other relevant areas include where the agile team didn’t deliver value, focus areas that require development, and what was confusing about the sprint.

Here, it’s important to talk about:

• What questions still remain unanswered?
• What outcomes still require further investigation?
• Is the team following processes that don’t deliver clear value?

Through a process of iteration, the Scrum team brainstorm to come up with real-time solutions to take over to the next sprint. Using retrospective ideas, the team populates the four quadrants of the retro template, producing a visual representation of their post-mortem.

Scrum teams can apply the four questions above in other retrospective templates or customize a template to conduct their post-mortems.

Retrospective template options

Team members can choose from retrospective templates to customize their sprint meetings.

Sprint planning can benefit from any of the agile retrospective templates below:

• The start, stop, continue template
• The four Ls retrospective template
• A starfish retrospective
• Sailboat retrospective
• Glad, sad, mad
• Mad, sad, glad

1. Start, stop, continue

In the “start” part of this retro, the agile team looks at the actions they’ll take in the next sprint. “Stop” refers to looking at the recently completed sprint to examine what didn’t work and the actions that the team should no longer take. “Continue” means identifying what worked in the current sprint and should be taken over to the next cycle.

2. Four Ls

Agile teams use this retro template to understand what they “Loved, Learned, Loathed, and Longed for” at the end of the sprint iteration. The team calls out what they appreciate, what the sprint taught them, what went wrong, and what they would’ve wanted more of (coffee, team members, time, etc.).

3. Starfish

Instead of using a retro that focuses on what worked and what didn’t, the starfish highlights degrees of efficiency in deliverables. Teamwork involves rating action items as levels of effectiveness to determine what methodologies they should keep, discard, and apply in the next round.

4. Sailboat

Scrum teams use the sailboat retro to determine their trajectory in unknown waters. Applying the sailboat retro means knowing what approaches inhibit progress, what new approaches will reap desirable outcomes, and establishing a direction for sprint planning.

5. Mad, sad, glad

The mad, sad, glad sprint retrospective is a technique that concentrates on the emotional status of teams. Scrum teams ask each other questions to create positive emotional support. These questions are also aimed at morale-boosting to create a positive atmosphere that supports teamwork and continuous improvement.

The agile retro can follow any template they choose or select one and customize it for their specific needs. Whatever they do, teamwork is vital to the success of continuous improvement.

Decide on your retro template today

Now that you understand how the sprint retrospective template works, you can customize yours for joint teamwork.

Instead of focusing on longed-for outcomes and functionalities, Easy Agile can help your Scrum team move from sad to glad.

Team retrospectives right inside Jira

Looking to improve how your team is working together? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives, to improve how you’re working and make your next release better than the last.

TRY EASY AGILE TEAMRHYTHM FREE FOR 30 DAYS

The perfect product launch is an elusive beast. As the launch date nears, the pressure mounts while the product manager deals with last-minute changes, bugs infesting the Jira board, and some network or server issue that threatens to ruin everything. You might have the perfect product management framework, yet the journey to the finish line is usually anything but elegant.

Whether you're launching a new product or releasing a new feature, product managers thrive on the excitement, exhilaration — and exhaustion! -— that come with the job, particularly surrounding significant releases. Even with careful planning, an exquisite product roadmap, and a neatly refined backlog, the final moments before launch always seem to end in a fight to the finish.

Before you place all the blame on your product management framework, or worse, your product team (Nah, you would never do that!), take a step back and breathe. We’ll walk through some ideas on how you can relieve some of the chaos on launch day. (Let's be honest, no drama on launch day would be just a little disappointing.)

Pre-launch planning

If you're using an agile product development methodology like Scrum or Kanban, you're already ahead of the game in terms of planning. Experienced PMs will have a roadmap with t-shirt sized epics and stories carefully laid out using established prioritization methods.

Based on your product strategy, you may choose to release new product features to production after each iteration. But sometimes, the product marketing plan requires a bigger splash. In this case, you can take advantage of press releases, major advertising events, or other high-visibility marketing opportunities.

Planning how you intend to release the product is as important as deciding what will be part of the release. Product development teams need to coordinate with product marketing to consider the following:

• Will you do a soft launch to a limited audience?
• Do you need to pre-release specific components to test pricing, marketing copy, or usability?
• Will you leave pre-releases in the wild until launch, or will you test for a specific time period and then pull them back?
• Do you have a hard date on which you must release (ex., Super Bowl Sunday), or is there some flexibility in the timing?

Answers to these questions drive the release strategy, which is then factored into your release plan and execution.

When it comes to determining what features to include in your product launch, you can choose from a variety of product management frameworks or use a hybrid approach and mix and match the methodologies to fit your situation.

The Kano model, AARRR (acquisition, activation, retention, referral, and revenue) theory, and OKRs (objectives and key results) all provide product management frameworks. These help product owners plan feature releases that align with the product vision and realize profitability objectives.

Remember: It's always a good idea to have a Plan B or even a Plan C to allow for unexpected events or issues that tend to rear their heads just before a launch. Atlassian has a great product launch template to get you started if you're working on your first release.

Launch day planning

A launch day checklist is your best friend on launch day. You might even want or need more than one list. A product launch has too many moving parts across too many teams for you to rely on memory alone. Your marketing, IT, and product teams will all play a role in the launch, performing necessary activities for their roles.

Particularly if this might be the first product launch in your startup, checklists help product teams think through details with clear heads well before launch day. The best plan is to ask each team to create their checklist and then meet as a group to align and coordinate each task's timing. Some launch day tasks are independent, ready to be tackled at any time. In contrast, others will be more time-sensitive or dependent on something else happening.

For teams with a few launches under your belt, these checklists hold the lessons learned from prior releases and, when updated after each launch, turn your team into a smooth-as-silk, product-launching machine.

Post-launch planning

As you know, a product launch is not the end game. Once the dust settles and everyone has gotten some sleep, you need to measure how the product performs. Planning how to measure the product’s initial key metrics allows product managers to communicate results to stakeholders early and as often as necessary.

Measuring key product metrics after a launch validates your decision-making of the product features, confirms you built the right product for the market, and helps you ask and answer the right questions when planning more feature builds and marketing strategies.

Important key product indicators following the launch can include total sales, top attribution channels, activation stats, and affinity sales. If you're launching a new feature within an existing product, you'll also want to keep an eye on retention numbers. A spike in churn rates could indicate a problem with the user experience or the underlying technology solution.

Beyond measuring the results of your release, you'll also need to prepare what's next. After your development team gets some shut-eye, they'll come back to work looking for their next assignment. You'll need to have your backlog ready for the next sprint planning ceremony, and then, it's back to business as usual. There may also be some immediate customer feedback that needs to be actioned.

Once you get your team off and running toward the next release, it’s time to take a look at your roadmap. You’ll likely discover new information when customers start using your new product or feature. It’s a good idea to leave some room in the roadmap to take on work discovered during the first few weeks of your launch.

Then there’s one last thing — CELEBRATE!! You and your team worked hard and accomplished something really cool! It’s easy to get caught up in the daily grind toward the next release. Take some time to pat yourselves on the back for a job well done.

Use your product management framework to tackle launch day like a rock star

With some planning and flexibility, you can set up your product team to make launch day look like a walk in the park. And the sooner you get good at this, the better. You'll always be launching something throughout the product lifecycle, from the initial MVP to new features to the end-of-life process.

Thorough roadmapping gets you off to a solid start, and as you get closer to launch day, you'll build out more of the critical details to ensure you don't miss anything. Cross-team coordination is essential, and checklists help open communication channels and get the entire team on the same page.

Early reporting on results builds confidence with stakeholders and is also a great way to show your team the results of their efforts.

Enjoy the adrenaline rush of launch day, but try to eliminate a little of the chaos and stress. As soon as you've launched, it's time to move on to the next thing. That's the nature of product development, and that's why we love it.

Simply developing a product doesn’t mean it’ll be a success. Plenty of elements determine how well a product is received — and a lot of that begins with product launch planning.

How will you unveil your product to the world? Who will be able to access your product when it first launches? What features do you need for the product's initial development, and what features should be saved for further down the road? How do you make sure everything is ready in time for the launch date you’re hoping for?

Product launch planning melds your development strategy and your sales and marketing strategy to ensure every department works together and aligns on key goals. It’s a whirlwind of a race to the finish line, but it’s also an exciting time for product developers. How will your product be received? What will customers and stakeholders think?

In this post, we discuss seven key strategies for successful product launch planning. Time for takeoff! 🚀

1. Set clear goals and define what success looks like

Set clear objectives and be realistic about what you hope to accomplish. Setting lofty, unattainable goals will distract from what matters most, and it can lead to disappointment, lack of motivation, and reduced morale.

Be clear about who on the product team is responsible for what and ensure team members outside of product development, including sales teams and marketing teams, are involved in product launch planning.

How will you go to market? What do you hope to accomplish with your launch? What product launch planning needs to happen before you can move forward? What pre-launch deliverables are critical to moving development forward? What roadblocks could prevent your success?

When you understand what you are trying to accomplish, it’s easier to tell when you’re successful. Don’t leave anything open-ended so that everyone on the team knows what you’re working toward and how to get there.

2. Get to know your audience

Great products are developed when customer needs are at the forefront of decision making. No matter what stage of product launch planning you’re in, you should always keep the customer journey top of mind. Consider how each decision you make brings value to your customers.

Customer personas describe important details about a target audience, such as pain points, behavioral patterns, demographics, goals, and buying habits. Deeply understanding who you are building a product for and what they need is vital to a successful product and a successful product launch.

Easy Agile TeamRhythm supports user story mapping, helping teams empathize with customers so that development and launch decisions can be made based on what will provide the most value to your target market.

3. Gather feedback and test, test, test

Test, test, test! We can’t say this enough. You need to continually test, ask questions, and gather market research.

Get your product in front of stakeholders and customers frequently to gather feedback along the way. The more you learn as you develop your product, the more issues you will sort out as you go, and the better the project will be in the end.

The testing process will also give you a deeper insight into what your users are looking for, so you can better meet customer needs. How do they interact with the product? What issues arise? What questions do they have? Do they understand how to use it? What features are they looking for?

Gather as much feedback as possible so you can continually improve the product leading up to the launch. Bring your stakeholders and customers into your process to better understand their needs and how you can provide consistent value.

4. Use comprehensive tools to track product launch planning

Product launch planning is a complex process with many moving parts, team members, and deadlines. Having the right tools is essential to the success of the launch. The whole team needs to be able to see what is planned, what is expected, and how each piece leading up to the launch is connected.

Establish a clear product launch plan template that guides the team forward. Backtrack from the desired launch date to create a launch timeline that recognizes everything that needs to get done before the product is put out into the world.

A product launch roadmap is an effective tool for tracking your progress. Roadmaps help teams align their vision, keep track of specific product launch dates, and provide a clear visual of the most critical prioritizations.

Learn how to create a product roadmap template with Easy Agile Roadmaps for Jira. They help teams align around a product vision and launch strategy to continually bring value to customers.

5. Focus on an initial great product, not features

Focus on your minimum viable product first. This is your top development priority before launching — no matter how tempting other fancy features may be.

Fancy features may be appealing, but they could slow down development, add unnecessary stress on the team, and cause unwelcome issues right before you’re supposed to launch your product. Put in the work to develop a product that meets stakeholder needs and delights customers. If this goes well, there will be plenty of opportunities to zero in on other features down the road.

6. Expect the unexpected

No matter how much feedback you gather and how many tests you run, there are always surprises when it comes to launching a new product. Launch day may not go as smoothly as you hoped. It’s okay if things don’t go exactly as you expected, so long as you’ve prepared for these possibilities and can adjust.

Extensive product launch planning will help you navigate surprises. It also helps to practice the motions beforehand. Give yourself time before the new product launch to review and practice the steps that need to play out. Rehearse your process to smooth out as many possible hiccups as you can. The extra time you spend running through the motions will also help ease the nerves of the team members involved in the launch process.

7. Hold a retrospective after the launch

After all is said and done, there’s still one more important step to your product launch planning. A retrospective helps teams examine the launch strategy and how everything played out. What went well? What didn’t go so well? And what can be learned from the process?

Even if you won’t launch another product any time soon, a post-launch retrospective is a great opportunity to learn from your experience. You can take these insights and success metrics into account when launching future features or other products down the road. Plus, it gives the team a chance to debrief after launch activities conclude.

Let’s recap those strategies one more time:

1. Set clear goals and define what success looks like.

2. Get to know your audience.

3. Gather feedback and test, test, test.

4. Use comprehensive tools to track product launch planning.

5. Focus on an initial great product, not features.

6. Expect the unexpected.

7. Hold a retrospective after the launch.

Learn more on the Easy Agile blog

There’s more where this came from. We’re dedicated to helping teams work better using agile tools and practices. We make simple, collaborative, customer-focused plugins for Jira, and we regularly publish articles on strategies, agile information, and how-to guides for product managers and agile teams.

Follow us on LinkedIn for the latest agile resources, guides, and product news.

We often get questions about why product roadmaps are considered an agile tool. To some, it seems quite “un-agile” to set concrete dates for a long list of tasks you will likely never get done.

That assumption couldn’t be more wrong. It presumes that a product roadmap is an old, overdone practice more akin to Waterfall predecessors like the *cough*Gantt Chart *cough*. This is not the case. Gantt Charts are for task dependency, and they assume that work will be completed in a linear fashion.

On the other hand, a true product roadmap is completely subject to change. It’s a living document meant to serve as a guide. The roadmap shows what a team needs to accomplish to create specific features or otherwise complete tasks that will provide the most value to customers in a certain timeframe.

This flexibility allows product development teams to make the most informed choices. To help teams do this, we built the simplest and most flexible roadmapping tool for Jira (more on this later). Here, you’ll learn about the benefits of using product roadmaps, the guiding principles of the roadmapping process, and how to use roadmapping tools effectively.

What is an agile product roadmap?

Agile is a broad term for a non-linear way of working that prioritizes flexibility and collaboration. This working style helps teams iterate as they go rather than stick to a rigid plan that doesn’t adapt to new information.

Think of agile as the complete opposite of an assembly line process for making a product. An assembly line has a strict plan where one step happens after the next. Each piece falls into place one after another without extra input or iteration.

🖍 Great for an assembly line of Crayola products, not so great for software development. 📱

Rather than use the assembly line approach, agile teams work collaboratively and iteratively on new products in order to detect roadblocks early, before they can cause a delay. And, Product teams use agile tools to provide clients and stakeholders value on a consistent basis.

Basically, agile product roadmaps are key to producing a great product.

They provide a smooth and collaborative planning process for development teams while maintaining the strategic objectives and product vision stakeholders expect. On top of all that, the flexibility provided by agile product roadmapping delights customers by consistently meeting their evolving needs, whims, and desires.

The benefits of roadmapping for product management

There are many benefits of roadmapping for everyone involved. Roadmapping assists product managers, helps the development team collaborate, gives stakeholders a clear view of the process, and ensures customers are continually pleased with product features and functionality.

Effective roadmap tools can provide the following benefits:

• Enable teams to align their vision around product features
• Provide a clear visual of the most critical prioritizations
• Ensure short-term product goals are met as soon as possible while monitoring and adjusting long-term goals
• Align all team members on what’s most important at any given time
• Keep track of specific product launch and release dates
• Maintain the product vision and business goals
• Ensure all stakeholders can view and give feedback on the current product plan
• Ship a product and solve issues relatively quickly
• Bring constant value to stakeholders and customers

For most teams, it’s truly the beating heart of product development.

4 guiding principles to get the most out of your product roadmaps

We’re obsessed with roadmapping and the many agile strategies that help teams work more effectively. So, we pulled together a list of the most important guiding principles that will ensure your agile team gets the most out of your product roadmap.

1. Focus on themes of work, not features

In the simplest form, themes represent high-level groups of work (like epics). In an agile product roadmap, themes should be customer-focused, unlike traditional waterfall roadmaps where themes tend to focus on business objectives.

Examples of themes include:

• Customer onboarding experience
• Reducing tech debt
• Customer satisfaction and engagement

By grouping work into themes, teams are able to tell a story about where they are headed as well as the goals, objectives, and outcomes that will get them there. User stories provide high-level visualization so that teams can answer critical questions:

• What are we doing?
• Why are we doing it?
• How does it link back to our Objectives and Key Results (OKRs)?

2. Think of the roadmap as a living document

Product managers need to educate their stakeholders on the true purpose of the product roadmap to manage expectations and ensure everyone is on the same page.

A product roadmap is not a promise. It’s a living document that’s meant to serve as a flexible guide.

You need to teach all stakeholders that the roadmap represents chunks of work, such as new features, functionality, and metrics customers value most at a specific period of time. It’s inevitable and expected that customer needs and preferences will change. The roadmap should be adjusted and amended to reflect these changes as time goes by.

The agile product development process should change to maximize the value customers experience. This is what it’s all about!

3. Actively collaborate with stakeholders

Involve everyone in the process, including internal stakeholders, external stakeholders, and the full development team when planning, reviewing, or adjusting the roadmap.

The product manager doesn’t need to be the only one representing the customer’s voice. By gaining the perspective of developers, the sales team, customer support, and engineers, you get a holistic view of the customer experience. This will give you a clear view of what your customers value to determine what should be done when.

4. Ensure the roadmap is accessible to all stakeholders

The product roadmap should be the team’s single source of truth, representing the plan of execution against the company's Objectives and Key Results (OKRs).

Understanding what’s going on and why each person is doing what they’re doing is crucial to establishing transparency and confidence in your team.

The roadmap represents the team’s overall vision for a period of time. Ensuring the roadmap is accessible to all stakeholders achieves organizational alignment.

Product strategy with Easy Agile roadmaps for Jira

We teased above that we’d tell you more about Easy Agile Roadmaps. We designed the simplest and most flexible roadmapping tool for Jira. Our roadmap software helps teams align around a product vision to sequence the most critical features for customer delivery.

Easy Agile Roadmaps are designed for everyone involved in the product development process from the product manager to the dev team to key stakeholders and customers. It works seamlessly with both Scrum and Kanban Jira Software boards. And, of course, it’s completely agile. Like, Simone Biles flexible.

Say goodbye to clunky Excel sheets, one-off Powerpoint presentations, and static Gantt Charts. Easy Agile Roadmaps can create a visual roadmap timeline that’s flexible, iterative, and easy to use. Split scheduled work, add date markers, use Quick Filters, track your progress, and export the roadmap as needed. The tool uses a simple drag-and-drop functionality for a clean user experience, no matter the needs of your team.

We’re so sure you’ll love it, you can try it free for 30 days. If you have any questions, our team is ready and waiting to hear from you, or watch an on-demand demo of our roadmapping app in action.

Let's face it! Project management for agile teams can include a lot of tough calls, from managing product owner expectations or undefined quality standards.

Sure, you have good days and bad days. But why not set your sights higher and aim for the ideal day?

To help you do just that, planning poker, also called Scrum poker, uses playing cards to simplify agile estimating and planning. The result? Your agile estimating and planning process runs more smoothly, and your development team increases its productivity.

In this article, you’ll explore the driving force behind planning poker,  how it helps estimation, planning poker’s history, and how to play this game.

The driving force behind planning poker

The purpose of planning poker is engaging the whole team in collaboration. Scrum poker makes it easier to make valuable time and effort estimates so your team can create satisfying deliverables.

Instead of team members verbally expressing their estimates, they use a deck of playing cards to speak for them. Drawing cards and simultaneously placing these playing cards face down eliminates bias. Everyone follows this route in the estimation process, which supports individual estimates and negates peer influence.

Other project estimation techniques use time to determine how long a task will take. Agile estimation uses story points. These story points refer to the level of effort to undertake a task.

In planning poker, the whole team assigns story points to each task. Each story point is a visual representation of the amount of work to be done and the effort that must go into completing each task. This method wins out over time since it is visual and focuses on effort involved instead of time constraints

Work estimation in agile development

The estimation process is vital to team members because it determines how much work will go into each sprint. Dividing the product backlog into bite-sized tasks helps evaluate the workload.

As a Scrum master, you have a difficult role to play. At the end of the ideal day, you want the product owner's user story to be exemplary. Simultaneously, as the Scrum master, you have a Scrum team to manage.

Agile development is a critical process that you need to control. Get the user story and story points right, and you're halfway there. Master the estimation process and sprint planning, and you control the product backlog and retrospective.

Software development teams can either use physical playing cards or software for planning poker. Using software that includes a Jira plugin is vital when you have distributed teams. When you have a Jira plugin, everyone can participate in and streamline the estimation process.

History of planning poker

Software development teams used to use another team-based estimation technique, Wideband Delphi. Although similar to planning poker, it took too much time to reach consensus with this technique.

James Grenning found that Delphi didn't work as a structured estimating approach and came up with the idea of playing poker in 2002. Grenning found that a physical deck of cards was an engaging approach for agile teams to make work estimates. He also found that Scrum poker worked better than Wideband Delphi.

Planning poker is more inclusive. The deck of cards ensures Scrum team participation in work estimates, and everyone must continue to participate until consensus is reached.

In 2002, Mike Cohn developed mountain goat software and stepped in with a deck of digital cards to use in planning poker. Scrum teams can use these digital playing cards from remote locations to improve agile estimating and planning and have some fun along the way.

Let's explore the ins and outs of the poker session and how to play the game.

What Scrum teams need for a poker session

Agile teams need a few essential items for their planning sessions. These items include:

• A deck of cards
• Estimators (the agile team)
• A moderator
• A features list
• An egg timer

Choose your playing cards

In Scrum poker, team members (estimators) each have a deck of cards. They use these playing cards to indicate their high or low estimate on how long each item on the list of features will take to complete. These list features can be the user story, story points, or ideal days to complete sprint planning.

The playing cards the development team use will follow a Fibonacci sequence. This Fibonacci sequence follows the 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 pattern, where each consecutive number is the sum of the two preceding numbers.

Alternatively, team members can use a different deck of cards where the value of each number has a fixed ratio, such as 1, 2, 4, 8, 10, 12 and so on.

Different card decks provide adapted sequences, such as 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, and 100. Other commercial decks have cards to indicate that the agile team needs a coffee break or an infinity symbol which means that it is impossible to complete a task.

Similarly, team members can adopt a standard deck of cards for Scrum poker. Here, the team members use the Ace, the 2, 3, 5, 8, and the King.

How to play Scrum poker

Every Scrum team will have different goals, but the general sequence for playing planning poker is as follows:

• All team members have their own deck of cards except for the moderator.
• Team members ask the moderator (often the product owner) questions about themes, user stories, story points, product backlogs, agile retrospectives, or whatever else they need for their agile estimating and planning process. Questions typically surround the product owner's acceptance criteria. Questions can include whether the backlog items are complete and what the next best step is to complete the sprint.
• Once the moderator answers the agile team's questions, each team member selects a card estimate. That represents how long they think the work item will take.
• Team members then place their cards, face down, on the table or use a Jira plugin for distributed teams.
• Playing cards are placed face down to prevent anchoring, or influencing each other's evaluations.
• The moderator reveals the Scrum team's cards to view their estimates.
• If team members have a high or low estimate compared to other team members, they need to explain their reasoning. The agile team can ask more questions for clarification. This questioning period is often limited by using an egg timer.
• The process is repeated until the agile team agrees on the estimate of how long it’ll take to complete each user story.
• Agreement is frequently reached on the second or third draw of the playing cards for each work item.

Agile estimation that involves the whole team

Planning poker is an accurate, collaborative, team-building method of estimating the work for each user story.

While you prepare to use planning poker in your next product roadmap planning meeting, consider Easy Agile TeamRhythm. The app helps you group Jira items into themes so stakeholders can easily keep track.

One of the core functions of an agile software development team is effort estimation. You can't properly prioritize a product backlog without first having an idea of the amount of work it will take to finish each of its user stories. One agile estimation technique is planning poker. Agile development is a collaborative pursuit, and planning poker is a consensus-building exercise that gets your entire team involved in the estimation process.

Software development teams use planning poker to assign effort (for example, story points or ideal days) to items in their product backlog. Sometimes also called Scrum poker, it's a gamified way to build consensus by allowing all of the Scrum team members to participate in the estimation process. Physical or digital poker cards are used to facilitate a collaborative planning session. ♠️

Here, we give you a how-to guide to planning poker. First, we'll show you how to play it in the context of a sprint planning meeting. Second, we'll look at some of its benefits as an estimation technique. Then, we'll see why planning poker can be used in product roadmap planning. It can help get your stakeholders involved in a consensus-building estimation session around your product's customer themes.

Playing planning poker — agile collaboration

One of the critical activities for agile teams during a sprint planning session is estimating the amount of effort it will take to complete each user story in the sprint. A common way to do this is to allow a single person, like the product owner or a software developer, to assign story points to each user story. Alternatively, you can use planning poker as an estimating technique to get the whole team involved.

A planning poker session is a fun and collaborative way to gamify sprint planning. After all, the Agile Manifesto highlights the value of collaboration and interactions in software development. Planning poker is a great way to adhere to those agile principles.

So, it's sprint planning day. When your team members are gathered, do the following:

1. Set the stage. If your team is new to planning poker, explain the process. They'll use playing cards to estimate the size of each user story in the next sprint iteration. The product owner or Scrum master will act as the moderator, all team members will play, and there will be plenty of room for discussion and questions throughout the session.
2. Hand out the poker cards. Give each player an identical set of numbered cards. We recommend using the Fibonacci sequence — 0, 1, 2, 3, 5, 8, 13, 21, etc. (To read why this sequence is so effective for estimating, see Mike Cohn of Mountain Goat Software's explanation.) And by the way, if you can't meet in person and are planning as a distributed team, then you can try planningpoker.com as a way to conduct your session remotely. 😃
3. Read a user story. The moderator reads the team members a story from the sprint. They should provide as much detail and context as possible to help the team estimate the work involved.
4. Discuss the story as a group. First, let the team ask any clarifying questions about the user story that was just read. Then, open the floor for discussion — each team member can describe what it will take to get the story done, any dependencies blocking the work, and who on the team might need to be involved in its effort.
5. Play cards. Now, it's time to play the game. Each team member submits a card (face down!) to the moderator. When all the playing cards are submitted, the moderator reveals what each one estimates. In an ideal world, all of the numbers match! This means there is perfect team consensus about the effort required for that sprint item and you can move on to the next one.
6. Discuss and estimate again. Most likely, there will be some difference in the initial estimates. This gives each team member a great opportunity to provide support for why their estimates were either higher or lower than the others. Then, you can do another round of submitting and revealing cards to see if there is further consensus. Tip: Let the moderator decide when to end the round. Remember, you don’t need a perfect story point consensus for every user story.

You did it! Your sprint is planned, and the entire team gained a shared understanding of how each member perceived the effort and work needed to get each user story done.

The benefits of planning poker agile estimation

As an agile estimating and planning technique, planning poker has its pros:

• It encourages collaboration. As a cross-functional team, it's important that each team member has a voice during the estimation process. As each estimator provides their perspective on a user story, the group better understands how they arrived at their conclusion.
• It drives consensus amongst your entire team. With each round of planning poker, the team’s estimates are more likely to converge.
• It has documented merit as a more accurate way to estimate (versus a single person providing the estimates).

In a study published by ScienceDirect, planning poker was used to estimate half of the work of a software project. There were two discoveries. First, planning poker estimates were statistically higher than individual estimates. Second, the poker estimates turned out to be more accurate than the individual estimates for the same tasks.

Planning poker for roadmap planning

Planning poker is a fun and effective way to gain an accurate estimate for your product backlog items. But, why not also use it for strategic planning sessions like roadmap planning?

In our definitive guide to product roadmaps, we discuss how roadmaps focus on big-picture, customer-centric themes, as opposed to individual features. We also highlight that developing your product roadmap should be a collaborative process (just like sprint planning) and should involve multiple stakeholders.

So, go back to the steps above. Think about how you can use planning poker cards to get your relevant stakeholders to estimate the relative size of each customer theme in your product roadmap. It will be a fun way to get a big-picture consensus of your organization's product vision.

Grouping your themes

Planning poker is a collaborative way to get the whole team to help estimate the work involved in a user story. It drives consensus and tends to be more accurate.

If you use Jira to conduct your sprint planning meetings, you already have a tool that organizes your user stories and product backlog. As you try planning poker in your next product roadmap planning meeting, give Easy Agile User Roadmaps for Jira a look. It provides the ability to group Jira items into themes that your stakeholders can easily see. Happy playing!

For a lot of people, 2020 isn’t quite going as expected.

Maybe you’ve had a conference or two cancelled (like the Atlassian summit 😭). Perhaps your big team planning event is on the backburner. Or maybe your entire workforce has been told to work from home until further notice.

Amazon has stopped all non-essential travel and a number of big tech companies have encouraged employees to work from home, including Apple, Google, Microsoft, Twitter, Facebook, and HP (in some or all regions).

You think you’re disruptive? Well, clearly you haven’t met COVID-19!

The new pandemic has shaken things up. Record numbers of organizations are looking for ways to quickly adapt and transition their teams to working remote. It’s a huge challenge when you consider that agile is typically designed for face-to-face interaction - especially critical events like quarterly PI Planning.

We’ve put together some thoughts to help you quickly transition your team to distributed agile, based on our own experiences and working with big organizations who have been working with remote team members for awhile now. First thing’s first...

1. Don’t panic (about distributed agile)

We’re not qualified to tell you if you should panic about the pandemic (seriously though… you don’t need that much toilet paper). But we are qualified to tell you that a remote workforce isn’t as scary as it sounds. You’re going to be just fine.

Organizations like yours have been doing their thing with a distributed agile team for years now. One of our customers has a large distributed team and only does remote PI Planning. It's possible to pull it off.

2. Lead people on how to work from home

Some of the people on your team probably haven’t worked from home before. At least, not for an extended period. So, offer guidance on what’s expected and how they can make the most from working at home.

You know... like business up top, sweatpants on the bottom, and no one on the conference call will be any wiser.

But seriously, it’s a good idea to share guidance like:

• What equipment they’ll need
• A list of software and apps to download (with licensing info)
• Where to find information and access files (a single source of truth is best at all times, but especially when things are already a bit overwhelming)
• How to communicate virtually
• Ideal environments for focus and productivity
• How to block out noise and distractions
• Expected work hours
• How to switch off and take breaks

But a little guidance will go a long way in helping everyone feel more “at home” with the new work situation.

3. Encourage information sharing

You might already have a distributed agile team who are experienced with working remote. So, encourage the experienced remote workers to champion the practice and lead others.

Create a Slack channel or other environment dedicated to discussions about working from home, so that people can share tips and experiences, and ask questions. At Easy Agile, we've created a #remote channel to share our setups.

4. Get the right tools

If your team is working remote for the first time, they might not have all the bits and pieces they need at home to do their job, attend meetings, or show up properly to a remote PI Planning event.

Depending on their role, they may need:

• Computer - A desktop and monitor setup or a laptop with sufficient processing power for everyday tasks
• Meeting equipment - Webcam, headphones, and working mic
• Your preferred communication apps - Slack, Zoom, Google hangouts, Skype, or Microsoft Teams
• Security measures - Password managers, VPNs, and antivirus software
• Your project management tool - Jira, Trello, Asana, or Smartsheet
• Easy Agile Programs for PI Planning in Jira

5. Look at this as a pilot

More people want to work from home and it makes a lot of sense for businesses to encourage this new way of working. It can save a lot of money (one estimate suggests $10,000 per person per year) when teams stay at home. And you can save hundreds of thousands per PI Planning session when you don’t have to pay for flights, accommodation, and event space for a team of up to 100.

The remote work trend isn’t going away - even after the pandemic dies down. So, look at this as an opportunity to try distributed agile if you haven’t already. You could find it’s a better, more cost-effective way for you to get stuff done and give your employees what they want.

6.Trust your people

Nobody likes to feel watched while they’re working 👀 But especially not while they’re working from home. At home, your employees will probably:

• Face more distractions (like kids!)
• Step away to put a load of washing on
• Grab a coffee (and probably a few other things 😋🍛🍫🧁) from the kitchen

In between all of that, you need to trust that they’ll get their job done, do their best, and be productive - even if it happens outside of regular business hours.

Fortunately, if you’re agile, you likely have built a culture of trust already. So, keep up with regular communication, virtual standups, and transparency. This should be enough to monitor progress and keep your people accountable without micromanaging

7. Stay social

Even if you can’t meet face-to-face, create opportunities for your teams to come together virtually, socialise, and chat. Set up a non-work Slack channel, do regular video calls, and talk about more than just work. People, relationships, and connectedness matter even more when you can’t be in the same room together.

8. Get better at risk management

When all of this blows over (and it will), you’ll come out a much stronger organization than before. If a single team member, a whole team, or your entire organization need to work remote in the future, you’ll be able to easily switch gears with minimal disruption.

Use this opportunity to uncover risks you might not have considered previously. Ask questions like:

• What if half of us get sick and can’t work for a few weeks?
• What backup options are in place for our internet connection, files, and communications?
• What if our building is suddenly inaccessible?
• Become more aware of potential risks to your company so you can be better prepared in the future.

9. Look on the bright side

While a pandemic isn’t an ideal scenario, it’s okay to look for the positives, like:

• Your teams may find they love working from home
• Some distributed agile teams will find they’re actually more productive
• You'll get greater work/life balance
• No commutes
• More quality time with family
• Reduced emissions from cars and planes
• Quieter roads with fewer traffic jams and accidents

And maybe… just maybe… some of these changes will stick around for the better 🤞

Waste is expensive! 💸 It’s paying someone not do any real work, paying for supplies you don’t need, or paying for team members to sort out a preventable issue. Lean agile aims to eliminate wasteful resources and tasks for improved efficiency and reduced costs — while never sacrificing quality. In fact, lean agile prioritizes bringing value to the customer with every decision that’s made.

Lean agile is a development method that helps teams identify waste and refine processes. It’s a guiding mindset that facilitates efficiency, effectiveness, and continuous improvement.

Consider this: You probably work a lot better when your desk isn’t completely covered with a mess of things you don’t need. When you eliminate distractions and waste, it establishes an organized workspace and workflow. This helps you focus on what’s most important, ensuring you work efficiently and effectively.

Here, you’ll learn more about the development of lean, the benefits of lean agile, and the five core principles of lean.

The development of lean agile

Lean agile, or lean software development, originates from the principles of lean manufacturing. The concept was brought into manufacturing to improve profits by reducing costs instead of solely relying on increased sales. If a company can eliminate waste and become more efficient, it can save money, thereby increasing overall profits.

Lean agile is an agile methodology that, in basic terms, is quite simple: improve efficiency by eliminating waste. Unlike traditional, waterfall project management, which dictates a set plan laid out by a project manager, lean agile strives to reduce all tasks and activities that don’t provide real value. This helps ensure everyone involved in a project or product development can work at optimal efficiency.

If you’re looking to dive into the history of lean agile, Lean Enterprise Institute Inc., founded in 1997 by James P. Womack, PhD, is a leading resource for lean methodology. It aims to help people and teams work better through lean thinking and practices.

Lean practices are popular because they can be applied to other agile approaches and software development methods. Lean agile provides a clear application for scaling agile, which is often difficult for large or growing organizations.

The benefits of lean agile

In case you’re not on board with lean agile yet, let’s review its main benefits.

Waste less time

Time is wasted when processes don’t run smoothly. In lean manufacturing, it’s important for goods and services to be delivered quickly and effectively. No one's time should be wasted on the job, and companies should aim for shorter lead times without sacrificing quality.

Wasting time in any industry is expensive, but it’s particularly important to pay attention when working in agile software development. Even a small bottleneck or broken process can completely throw off a workflow or product deadline. Lean agile helps development teams manage time effectively to ensure everyone is utilized, no one's time is wasted, and roadblocks are anticipated in advance.

Reduce costs

When businesses eliminate waste, they save money. In its original form, lean manufacturing ensured companies had the right amount of materials, employees, and working hours at any given time. Overproduction, overhiring, or simply having too many materials to store are expensive wastes that can be eliminated through better management of systems and processes.

Any business, no matter the industry, will save money with improved efficiency. Lean agile ensures that waste is continually eliminated and agile teams continue to fine-tune processes for optimal efficiency.

Improve work quality

With lean agile, it’s not only about efficiency — it's about maintaining efficient processes while bringing a quality product to customers and stakeholders. When businesses intentionally improve processes, they remain competitive. Lean principles consider the customer value of any action or decision to ensure needs are always met or exceeded.

The five principles of lean agile

There are five core principles for implementing lean methodology:

1. Value
2. Value stream
3. Flow
4. Pull
5. Perfection

These principles describe a five-step process that guides the implementation of lean techniques for manufacturing, software development teams, and other agile practicing industries.

1. Identify value

The first step requires you to step into the shoes of the customer. Value is what the customer needs and wants from a specific project or product.

Consider from the customers’ point of view: What are their expectations? What are they willing to pay for? How do they want their needs met?

Sometimes, customers may be unable to define exactly what they’re looking for — especially if it’s a new product or technology they’re unfamiliar with.

In any case, the project cannot move forward without clearly identifying what it will take to provide customer satisfaction. You’ll need to identify the end goal (value) customers are hoping to find with the product or service.

2. Map the value stream

Next, the team visually maps each of the steps and processes it will take to bring the product from inception to delivery. By making each step visible and always keeping the value top-of-mind, it’s easier to see which steps don’t directly contribute to continuous delivery. Once wasteful steps are found, the team finds ways to eliminate those steps or reduce them as much as possible.

Getting rid of waste ensures your company doesn’t unnecessarily spend money on steps and processes that don’t add value. And — most importantly — the customer gets exactly what they’re looking for.

3. Create flow

Once the waste is eliminated from the value stream, the next step is ensuring the remaining processes work as effectively and efficiently as possible, which means no delays, disruptions, or bottlenecks. It’s important for the steps that create value to work in tight sequences to ensure the product flows smoothly toward the customer.

In order to achieve this kind of agile transformation, lean businesses must train their employees to be adaptive and multi-skilled, create cross-functional teams, break down and reconfigure steps in the production, and balance employee workloads.

4. Establish a pull system

With enhanced flow, your team can deliver products and services faster. A pull system enables “just-in-time” manufacturing and delivery, limiting inventory and work in progress (WIP) items by only producing enough to meet customer demand.

By establishing a pull system, you create products and services as needed as opposed to creating them in advance, which leads to a growing inventory or list of tasks that need to be stored and managed — draining your bottom line.

5. Seek perfection

By completing steps 1-4, waste is eliminated — for now. However, the work is never done. There is always a process that could be improved, and there will always be steps in project and product development that waste time and money or don’t deliver value. That’s why the fifth step of seeking perfection is key.

Lean takes time to implement, and going through the process once is not enough. Build a continuous improvement mindset into your company culture, and never settle for the same old.

Lean agile made easy

Lean prioritizes the elimination of waste to improve efficiency. This helps teams continually improve their processes while emphasizing the tasks that bring the most value to customers.

If you’re looking to learn about how agile principles work with other development approaches, we recently covered eight different software development methodologies, including rapid application development, extreme programming (XP), and other agile frameworks.

Easy Agile is dedicated to helping teams improve their processes and agile methods. Our Jira plugins help product owners, Scrum Masters, and development teams align around product goals, workflows, and customer needs. The tools are simple to use, collaborative, flexible, and they work seamlessly with Scrum, Kanban boards, and other agile processes managed in Jira software.

You can contact our team or watch a demo to learn more about our tools and follow our blog for the latest content on Jira, agile, lean, and the development process.