Stories by Easy Agile

Software development is incredibly dynamic and results-driven, with rapid innovation and technology changing all the time. So if you want to keep with it all – just like you do with the Kardashians – you need a flexible way of working that suits your organisation. If you’re struggling to work out how to coordinate multiple agile teams and scale agile transformations, Scaled Agile (SAFe) might be for you.

But what exactly do we mean by SAFe, and how can it help your enterprise work better together and more effectively serve your customers?

Read on as we discuss the differences between SAFe and agile and how you can use SAFe within larger companies. Below, we’ll cover why agile is still best for small teams and why enterprises should consider scaling up.

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

Try Easy Agile Programs

Join a demo

What is SAFe?

Scaled agile framework, or SAFe, makes it easier for large enterprises to implement lean agile practices to improve their product and meet stakeholder requirements.

SAFe is a body of knowledge that has structured guidance on roles and responsibilities, work planning and work management, and core values.

SAFe is a combination of different agile practices, but it introduces one unique aspect: lean thinking.

Lean thinking should ensure no resources go to waste during the software development process. Trust us, your thrifty side will thank you. #ZeroWaste 💃🏼

SAFe also encourages people to apply systems thinking to three crucial areas: solutions to pain points, workflow management, and revenue streams.

Here, solutions refer to products, services, or systems that are delivered to the customer. Large solutions have several interconnected parts, so managers need a broader approach to see how they fit into the bigger picture.

People who follow the SAFe framework should think about the involved stakeholders and processes. If any organization wants to optimize how their teams work, they need to become cross-functional, remove silos, and make new working arrangements with suppliers and clients.

This can be a big change for many large companies with poor cross-functional collaboration.

The enterprise also has to define how value flows from concept to cash in the solution department value streams, which is a series of steps used to create value in SAFe. Plus, it's management’s job to maximize value flow across organizational as well as functional boundaries.

People often confuse agile to be the same as SAFe, but they have some key differences.

Try Easy Agile Programs for Jira

SAFe vs. agile: How do they differ?

Agile is a repetitive product development method that helps ensure the continuous delivery of tasks assigned. In other words, it's like Monica from Friends. She’s reliable and good at what she does.

In agile, cross-functional development teams work off a single backlog and break work into sprints, which means breaking down tasks into time-defined, smaller groups. This makes every person aware of what is expected of them, which, in turn, promotes productivity and increases the likelihood of better results.

That said, agile is mainly designed for smaller teams. Think 10 or fewer people. But if you’re an enterprise, don’t start sweating yet. In its simplest form SAFe is an agile framework for businesses that operate on an enterprise level. Enterprises are usually corporations that have hundreds, if not thousands, of employees and teams. So the number of people engaged is definitely larger.

The benefits are different as well.

Agile provides project managers, leaders, sponsors, and customers with various benefits, including faster turnaround time, resource wastage reduction, improved strategic focus on customer needs, better team collaboration, and feedback.

The biggest advantage of SAFe is it’s suited for enterprise problems. It keeps the size of the teams in mind as it helps increase productivity, make efficient project framework planning, and quicker codification of agile practices.

Having said that, SAFe and agile aren’t exactly on different planets.

The essential SAFe and agile core values are similar – but they aren’t exact. SAFe principles prioritize the following four:

• Alignment
• Transparency
• Built-in quality
• Program execution

Whereas, the core values of agile include:

• Customer collaboration over contract negotiation
• Faster response to change over a plan
• Working software of work comprehensive documentation
• Individuals and interactions related to processes and tool

Achieve team alignment at scale with

Easy Agile Programs

Join a demo

So, SAFe inspires lean-agile decision-making across large product management projects, while agile development promotes self-organizing, autonomous teams..

Organisations operating on a larger scale should consider scaling agile – which is exactly what SAFe is. Keep reading as we discuss this in more detail.

Why enterprises should consider scaling up from agile

Before discussing SAFe further, you have to understand what happens to relationships and communication when teams get larger.

The larger the team, the greater the number of relationships. Every new person adds some individual perspective to the team, but they can also increase overhead communication.

Let’s explain things from a mathematical point of view.

Imagine a team that consists of seven members. The total number of one-on-one relationships within the team is 21. But when you increase to nine members, the relationships between every individual becomes 36. Yep, that's the difference it can make! *mind blown*

How does SAFe serve larger teams better?

You may already be familiar with Scrum and Kanban – both of which are agile frameworks and are most effective at the individual team level in sectors primarily born out of software development, including DevOps and portfolio management.

It also means that adopting these perspectives when multiple teams are involved won’t be useful. #Frustration 😔 Although large-scale scrum is a possibility, product owners and product managers often look for other solutions.

SAFe goes beyond the team level, which, in turn, results in better alignment across teams and workload visibility. You're also able to make better predictions related to dynamic market conditions and ever-changing customer expectations.

*enter PI Planning or program increment planning*

PI Planning within SAFe can ensure better collaboration and decision-making between teams. Team leaders can decide on features to work on next, identify dependencies, and develop a new plan for program increment in a much more effective and efficient manner.

So teams work with each other and not against. #Win 🥳

A full SAFe adoption can solve enterprise pain points and boost competencies

Keep reading as we discuss how SAFe solves large enterprise pain points in a way agile alone cannot.

Make processes configurable and scalable

Implementing SAFe for larger teams isn’t difficult – all you need to do is add a layer to the process map. And take your patience levels up a few notches. These changes can help the team visualize how the different teams can continue to work together harmoniously after any change.

In other words, business agility won't have to be compromised.

The Agile Release Train (ART)

An ART enables Scrum and Lean teams to experience the benefits of proper process alignment that the Program and Portfolio processes expand upon as the team starts to grow.

Clearly defined processes and roles

It’s normal for teams to face problems, but with SAFe, they'll get a better idea of how to solve them by improving their thought processes and utilizing specific tools.

What's more, the SAFe website has an in-depth explanation of concepts along with process maps that serve as visual aids to understand the said concepts and processes.

Scaled Agile improves team collaboration

SAFe helps large organizations carry out large-scale, mission intensive projects better. The combination of existing lean and agile principles can play a very positive role in facilitating better communication and control between multiple teams.

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.

Register for a demo

Try free for days

If you want to learn more about agile teams and frameworks, we have plenty of guidance that can help you ensure better results for your organization.

Easy Agile’s purpose is to find a better way to work. Back in 2018 we consciously acknowledged that what got us here👇🏼, won’t get us there 👉🏼. In other words, we have to change to achieve our goals. The real challenge is to proactively seek change rather than being forced into it.

"We believe there is a better way to work"

What got us here

When Easy Agile (then Arijea) first started out in 2016, Nick and I would spend a full third of our day discussing what we were going to do and how we were going to do it, (which is a pretty good idea when you don’t know what you’re doing!). It was these conversations, along with reading Thinking Fast and Slow, Deep Work and Small Giants which formed the basis of some of our company values and how we work at Easy Agile. We still talk a lot, not quite a third of the day, but it’s more around how we’ll work, rather than what we’ll work on.

A quick history: 2016 - 2018

A lot happened in the first few years of Easy Agile’s existence. We created some successful products, travelled around the world to Atlassian events and generally had a bunch of fun. We also built huge backlogs of work we’d never, ever start, let alone finish.

Back then our situation was a little different to most other software companies. We had more products than developers! At one point we had 5 products and 1 developer. This improved to 3 developers and 2 products, but even still, our internal systems and other non-customer-facing work never seemed to get started.

These early years were chaotic, which was entirely my fault. It was my reluctance to give up coding that meant I was lost in the weeds rather than zooming out and attempting to build a fantastic team. We were just plodding on, looking at our shoes and getting distracted by little things instead of stopping, reflecting and committing to our core purpose. I needed to change my ways to help the team improve. Thankfully I remembered a really cool video which eventually would become the impetus for me changing my focus from code to the team...

I’ve watched this video countless times over past few years. Every time I do, it makes me feel so lucky that I worked at Atlassian and was able to partake in ShipIt and Innovation Weeks. I highly recommend you take the time to watch it if you haven’t already.

The importance of Autonomy, Master and Purpose

The ideas this video presents around autonomy, mastery and purpose propelled me to think beyond simply how we work to think about the reasons why we work. Naturally, the first thing that comes to mind is money. Having enough money is vital to live a fulfilling life (which I’m proud to say we strive to provide at Easy Agile), however, as covered in the video above, more money is not necessarily a great motivator. It’s autonomy, mastery and purpose which provide that.

So whilst I was taking a step back to create a better way of working, I figured we may as well try to bake in autonomy, mastery and purpose along with a provision to prevent some undesirables from creeping in. The main culprits I had in my sights are bureaucracy, red tape, sacred cows, legacy systems and politics.

If you’re going to the effort to building an amazing team of talented people, taking time out of their lives to work for you, the last thing you want to do is get in their way with pointless rituals which just stifle their creativity and waste their time!

Gaining perspective by zooming out

Being a software company, Easy Agile’s heart beat is our software development process. However nowadays we do so much more than develop software. All of our team communicate directly with our customers daily via customer support, we have fantastic marketers, product managers and a data analyst. We needed a way of working which went beyond backlogs and estimation and brought everyone together to push in unison towards our goals.

We do our best work together in cross-functional teams so I wanted to bake that in from the start, rather than build silos as we grew. We started out by having everyone work off one backlog and scheduled all of our work in Jira (including Sean, our first marketing hire). However, as you can guess, this doesn’t scale. The details discussed at our planning sessions became irrelevant to most of the team. We ended up only skimming over most of the details which made planning and estimation mostly irrelevant.

In early 2019 I made it my mission to get serious about finding a better way to work. So I stopped coding (it was frightful founder-code anyway). Since then we’ve been through four revisions of our development process. We’ve even made “finding a better way to work” our motto.

The details of this transformation is beyond the scope of this blog post, however, let’s just say that we’ve gone from a chaotic, unmanaged backlog to a far more organised and considered approach to work. The current revision of our development process allows us to work on (and dogfood) our products and our internal systems simultaneously. It scales with us as we grow, encourages cross-functional teams and bakes in our company values as well as autonomy, mastery and purpose for all team members.

Shape Up by Basecamp forms the foundation of how we work

I was first made aware of Basecamp’s Shape Up in a comment Nick made on a blog post I wrote announcing one of the aforementioned revisions of our development process. It was 4 months later when I’d started my hunt in earnest for a better way to work that I remembered it and, upon re-reading it, felt it might just work.

In Shape Up you work in 6 week cycles which is just long enough to do something tangible, but short enough not to feel that the deadline is too far away. This is followed by a 2 week “cool down” where everyone is free to fix bugs, try out something new and gather themselves for the next six week cycle. At Easy Agile, we already worked in a “product” cycle, where we would focus on one product after another, so this idea fit in well.

Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The majority of our new features are built and released in one six-week cycle.

Shape Up goes on to propose the concept of “pitches” and “bets”. A pitch is a refined description of a feature or change large enough to have a meaningful impact on the company if it is successfully delivered.

Shape Up takes its name from the “shaping” process applied to forming a pitch. Shaping a pitch is simply taking the time to focus on the problem and define a good solution. You are encouraged to pull in people you trust to “hammer the scope” of your pitch so it is very clear what it does and does not do. This appeals to our “Engage System 2” and “Commit, as a team” values.

I’m not a betting type of person, and seeing as that viewpoint seemed fairly prevalent in the team, we came up with an alternative vernacular: Opportunity.

What is an opportunity?

Opportunities ratify the work of our Product Managers. They may take up to four weeks or longer to shape which is in stark contrast to other workplaces where product managers are responsible for “feeding the beast” (finding, or making up, work to keep the development team at full capacity).

Opportunities represent either 2 or 4 weeks of work. Anything less and it’s probably not really worth doing, or it is a small improvement, which is done by our Small Improvements team (more on that later).

Our cycle

Where Shape Up’s cycle is a total of eight weeks, we’re currently experimenting with a six week cycle. We have four weeks of work on Opportunities followed by a week of paying down Technical Debt, go to market and final Opportunity shaping. We round out with a couple of Dash Days (more on that later too).

1. How we shape and select Opportunities

Shaping opportunities primarily falls on the shoulders of our Product Managers, Teagan and Elizabeth. Anyone can raise an Opportunity ticket in Jira, but by doing so it also means taking complete ownership of guiding it through development, testing, production and monitoring its health and metrics after launch. For this reason we usually recommend working with a product manager to flesh it out.

The process of shaping and scope hammering is generally done with a few collaborators who can provide perspective on all of the moving parts involved in what you’re attempting to do.

Currently we attempt to select the Opportunities which will put Easy Agile in the best possible position to achieve our goals (aka our quarterly and annual OKRs). Opportunities which are not properly scoped or shaped will be sent back to the drawing board to come back around in another 6 weeks.

We are currently exploring how we can improve the Opportunity selection process. The betting table meeting described in Shape Up is one way to select what to work on, however we feel there is a better way which we haven’t quite put our finger on yet. Ideally each Opportunity will help us move towards of one or more of our top-line goals. Baking our OKRs into our work planning keeps them at top of mind throughout the year.

2. Opportunity team formation

The autonomy part of our development process really sings when it comes to team formation. With only one exception**, all teams are self-selected and formed of exactly three development team members (a senior, mid and junior team member - something we are still actively hiring for). Team members from product management, data analysis and marketing join to create truly cross-functional teams. This means when the Opportunity goes live, all of the required marketing material, documentation and other non-development work is ready to be rolled out allowing us to move on to Tech Debt / Go to Market / Shaping Week.

We chose three team members per Opportunity as this allows each team to self-serve their own pull requests. Our pull requests require at least two approvals to be merged. Having three team members reduces the disturbances and context switching being forced onto other teams.

**A small team works on bugs and small improvements on a 2 week Opportunity which is always selected. The team members for this team work on a rotation so everyone gets their go.

3. Tech Debt / Go to Market / Shaping and Selection week (yes - we need a better name)

In the week following the completion of our 4 weeks of Opportunity work, the development team takes a week to focus on technical debt or improving their development environment. We also use this week as a rollover buffer to close out any work which was not completed in the Opportunity weeks. We try to keep rollover to a bare minimum.

The marketing team will roll out any of the initiatives they built in the prior four weeks to support any new features which were shipped.

The Product Management team will crack on with finishing up the shaping of their Opportunities and have them ready to work through with the team for the next Opportunity cycle.

4. Dash Days

Dash days (formerly Inception Week) is a period of freedom and autonomy to work on a pursuit of your choosing which, when successful, will ideally lead us to think “How did we live without this before!?”. They are essentially a mix of ShipIt / Innovation Weeks / 20% Time which I experienced at Atlassian. They’re a great avenue to release the creativity of our team.

Some recent successful Dash Days projects.

1. Easy Agile Personas
2. Our Dev Container vscode setup
3. “Mr. Tulip” (our Slack bot which almost does everything)
4. In-product NPS
5. The Easy Agile Podcast
6. Our deployment dashboard (showing the number of days since a Cloud or On-premise deployment)
7. Powering our website with Sanity.io CMS
8. ea-kit (our own component library)
9. A new random forest churn model to better understand our customers frustrations
10. Our own logo/brand design framework

As you can see, there’s a great deal of diversity in the Dash Days projects we have shipped. Shipping is not a requirement of Dash Days, though. Quite often it’s best to take some time to try out some new ideas or build a prototype to put in front of customers.

A great example of that is a feature refinement developed by Sam and Angad, two of our newest front-end developers. They worked with our Product team to build a new way to create issue dependencies in Easy Agile Programs. Their definition of done was not releasing to production, but to get it on a test server which we used for customer interviews run by our Product Managers, Teagan and Elizabeth. The following Dash Days Sam and Angad took this feedback, refined the feature with the product teams' help and shipped a version to the Cloud version of Easy Agile Programs. So far the new dependency creation approach appears to be 10 times more popular! Success!

Dash Days is also a great time for team members to take advantage of their $5000 Learning and Development budget which each team member receives every year.

Shaping a new way to work

Introducing a Shape Up flavoured process here at Easy Agile has allowed us to gain focus and certainty in the work we choose to take on. It allows us to have long term goals without the need to build inflexible roadmaps. Our Product Managers are encouraged to take the time they need to focus and design amazing new solutions for our customers. The 6 week cycle grants us the flexibility to react to external changes or take advantage of new opportunities which arise without derailing the plans for the remainder of the year. We can take the learnings from our past Opportunities and feed them into the plan for the next, increasing our chances of success.

Easy Agile’s development teams are flexible and choose who they work with and what they work on. We constantly pay down tech debt and shun red tape, legacy systems and sacred cows. We work in cross-functional and fluid teams.

We’ve been able to adopt Shape Up and bake in things like Dash Days and our company values. We love that the way we work allows us (and encourages us) to stop, take a breath and express our creativity every 6 weeks. Tech Debt Week and Dash Days are also a great way to increase the focus of our development team on their main projects by deferring any small tasks which interrupt and distract them.

We believe a steady, life-inclusive and balanced approach where we bring our whole selves to work each day is better than burning ourselves out in the pursuit of unrealistic deadlines.

And finally, as we grow, we know that the system which runs Easy Agile will continue to change to help us find a better way to work.

There are many good reasons why so many scrum and agile teams are adopting story points.

1. Fast estimation

User story points allow you to quickly estimate the work involved in each item on your backlog, and how much work you can get done in a sprint or release.

2. Build consensus and collaboration

If one team member estimates 5 story points, but another estimates 12, it's an opportunity for the team to discuss what work is involved.

One person may have a more efficient way of doing things, or the other person may have a better understanding of the steps involved in doing the work. This discussion will help them share ideas, create a common understanding, build consensus, and create a more accurate estimation.

Compare this to estimating time. If you ask each team member to estimate the amount of time involved in a task, you’ll get 5+ different answers. Timing depends on experience and understanding. But most team members will agree on the effort required to complete a story, which means you can reach a consensus and move on with your story mapping or sprint planning much more quickly.

3. No artificial deadlines

Estimating time instead of story points forces you to come up with an artificial deadline, which can create unnecessary pressure (and probably won't be all that accurate).

Story points more accurately and practically reflect reality. In most cases, there is no set deadline - only ensuring tasks are done efficiently and in the right order of prioritization.

4. Better planning and forecasting

Story points can help you plan better in advance. For example, if you know that Johnny is going on holiday for a week, you can adjust your sprint so that your team doesn't over-commit. Or you can find another way to increase your capacity, like bringing on another team member or reducing scope.

5. Zoom in on the details

Story points force your team to think through the work involved in an upcoming sprint, and consider what's realistic. It's a time for your details-oriented team members to shine - and time for your big-picture thinkers to understand what needs to happen to bring their plans to life.

6. Get commitment

When your team knows they can achieve what's planned and they’re confident in their velocity, it's easier to get them to commit to the work and follow through confidently.

7. Be more adaptable

If the team size changes (maybe you add a new member or someone moves to another role), you have a built-in system to update your velocity (i.e. how many stories you can complete in a sprint) and adapt your workload accordingly.

8. Be just accurate enough

Story points help you estimate what your team can get done in a given amount of time. This kind of accuracy means smoother releases that go to plan - and is especially valuable when you have multiple teams with multiple dependencies.

But at the same time, story pointing makes it clear that your work is only an estimation, and you're not committing to getting X done in Y amount of hours. You won't know how long something will take until you do it - there are nearly always unexpected things that pop up.

Other methods might give you more precise timing, but it’s not practical to spend 30 minutes discussing the work that goes into every single story on your backlog. It’s much more practical to assign an “accurate enough” number, plan your sprint, and get to work.

9. Better capacity planning

You might not be able to fit all your top priorities into a release, especially if they’re complex, risky, or time-consuming. But story points can help you easily identify one or two smaller stories to fill your capacity every sprint or release.

Using story points also encourages you to find ways to increase your team’s capacity (rather than working longer hours). If you can mitigate risk, find ways to reduce effort, and bring the right people in the room to make complex tasks more simple… you’ll be able to get through more stories, more quickly.

10. Measure and improve performance

Story points can help you measure and improve performance by asking your team questions like:

• Did you complete all the work assigned during the sprint?
• Is your velocity going up or down over time, as you get better at agile?
• Was your story points estimate accurate?
• If not, how could you optimize your team's performance and ensure you work or plan better together?

Does everything in your backlog need user story points?

Some teams don't assign story points to every item in their backlog. They might just assign them to the user stories. They might avoid assigning user story points to bugs that come up during the sprint, particularly if they're not related to any of the stories originally mapped to the sprint. This makes sense since it's often tricky to estimate a bug - some take very little effort to resolve, while others are quite complex.

Your backlog might also include smaller jobs or technical tasks that would take anywhere from a few minutes or a few hours to complete. These tasks may not have story points assigned if they require very little effort.

But it’s important to note that these tasks still matter. They still deliver value back to the user. And they're essential as part of your goal: to deliver working software. But you can't always plan for them or estimate them ahead of time.

So, how do you incorporate them into your workflow?

You might need to discuss some different ideas and strategies with your team.

For example, you could set aside a buffer in your capacity to allow for an average amount of bugs and other jobs that don’t get story-pointed. That way, you can stay on track with the stories you have assigned to the sprint, while getting other items ticked off the list.

Either way, if your team is working on tasks that don’t have story points, you have to consider the impact on capacity. You will need to adapt, assess whether the sprint goal is still doable, and adjust your plans accordingly.

What happens if you get the estimate wrong?

While you should aim to make your user story point estimates as accurate as possible, you might have under or overestimated the amount of risk, effort, and complexity involved in bringing a story to life.

This might mean you don't get all the work planned for your sprint done. Maybe you need to move some of it over to the next sprint, which will mean reprioritizing and adjusting your user story map.

Fortunately, this process is pretty straightforward if you use digital user story mapping software like Easy Agile TeamRhythm.

Retrospectives or sprint reviews are a good time to discuss any issues with your team where estimates were off. Take some time to go through what happened, understand why more or less effort was required, and discuss how you might do more accurate estimates in the future.

Assign story points inside Easy Agile TeamRhythm

With Easy Agile User Story Maps for Jira, you can add and edit story point estimates directly on your story map. Simply select the story or issue and edit the story point field.

It will automatically update your sprint/version statistics with new totals, so you can see your capacity, arrange stories into sprint/version swimlanes, ensure you’re making the most of your velocity, and avoid over-committing.

Plus, your whole team has access to the user story board and estimates - perfect for in-house or remote user story mapping, online collaboration, and updating estimates at any point in the process.

Curious about Easy Agile User Story Maps? Features include so much more than story points, like:

• Drag and drop prioritization
• Visualized customer journeys inside Jira
• Sprint/version swimlanes for organizing stories
• Easily add or edit stories inside your story map
• See sprint/version statistics at a glance
• Easy collaboration with team members
  

Free Trial: Easy Agile TeamRhythm

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.

Backlogs are so full of potential, right? Ideas and possibilities for your product to become bigger and better than ever before.

But when you’ve got more than a few items on your list, backlogs are also overwhelming.

Without some kind of clear structure or prioritization, your team won’t know what to work on first.

They might work on whatever they feel like, whatever’s easiest, or most interesting, or not do anything at all.

You need a way to figure out what you should work on first. Not only that, but you need to make sure that what you’re doing delivers value to customers, makes sense for each release, fits into the bigger picture of your organization’s goals.

That’s where user story mapping comes in.

What is user story mapping?

User story mapping is a useful way to organize and prioritize your user stories so that you can schedule your work and design your releases.

It helps you visualize the customer’s journey through your product from start to finish, including all the tasks they’d normally complete along the way.

What’s a user story mapping session?

User story mapping is usually done in sessions over 1-2 days where you bring key people together in the same room.

During these sessions, your product manager (and sometimes other stakeholders) shares their customer insights with the team, who also share their ideas for the product.

Together, you brainstorm user stories, unpack the steps in your customer journey, list out any current issues, and put these onto a user story map. Your user story mapping session gets everyone on the same page about what needs to happen.

What’s a user story map?

A user story map is the artefact or visual board you produce as a result of a user story mapping session.

Your teams will refer to this map throughout each sprint to make sure they’re on schedule, coordinate dependencies, and keep sight of the big picture.

What’s a user story?

In order to understand what a user story map is, it’s important to take a step back and define one of the key components: the user story.

A user story is a goal or outcome that the user or customer wants to achieve. Usually, you’ll write user stories like this:

“As a [persona type], I want to [action] so that [benefit].”

A user story should be the smallest unit of work that can deliver value back to the customer.

You might also consider a user story to be a task that’s written from the user or customer’s perspective. User stories are usually added to your backlog, and from there, you can arrange and prioritize them, and plot them on a user story map so that they’re scheduled to a release or sprint.

Read more about user stories in our blog: How to write good user stories in agile software development.

What does a user story map look like?

User story mapping is traditionally done on a physical story mapping board:

But increasingly, companies are doing their story mapping digitally. If you use Easy Agile User Story Maps, yours might like more like this:

Whether you do your user story mapping physically or digitally, you’ll see both approaches have a few things in common:

• A backbone (the row along the top of the sticky notes), often consisting of epics
• Cards or sticky notes with user stories under each item in the backbone
• These stories are sequenced vertically from most important (to the customer) at the top, to least important at the bottom
• Horizontal cut lines or swimlanes define where your releases or sprints start and stop

(Psst: read more in our blog, Anatomy of an agile user story map.)

What’s involved in a user story mapping session?

A user story mapping session involves discussing and planning all the parts that make up your story map:

1. Your team will get together and decide on the backbone - the big steps that make up your user journey.
2. Next they’ll brainstorm user stories - all the little steps that make up the user journey and any issues (bugs or ideas) and add them to the backlog.
3. They’ll organize these stories under the backbone item they’re associated with.
4. Next they’ll discuss and estimate the work involved in each user story, assigning story points.
5. After that, your team can add cut lines to mark out what they’ll deliver and when - either by sprint or release. At this point, you might shuffle some stories around if it makes sense for the user to get them in the same release.
6. If everyone’s happy with the plan, the story map is done (for now) and it’s time for your team to start the first sprint.
   

That seems like an awful lot of effort. So, what’s the point?

What’s the point of user story mapping?

User story mapping benefits both your customers and your team.

Customers get more value delivered, sooner

helps you understand what your customers want. Because the focus is on the customer journey and what tasks they’d need to complete in order to use your product, it helps you prioritize work that’ll help fill in the gaps for customers and deliver value to them.

Teams prioritize and collaborate better

A three-dimensional view helps with prioritization because your team can see what user stories should be grouped within a release to deliver a new experience for users. For example, adding the ability to customize your profile isn’t all that meaningful unless you have a community aspect where users can view other profiles and/or interact with one another. User story mapping helps you fit all the pieces together - and make sure you can realistically deliver them within the sprint or release.

Plus, you can more effectively plan your work and collaborate as a team with your user story map. That’s because you can see the big picture and full customer journey before you start the work.

For more insights, check out our blog on why user story mapping.

What’s the alternative to user story mapping?

If you haven’t done user story mapping until now, you’ve likely been using another method to understand customer requirements and plan/prioritise your work.

The most common approach is known as the “flat backlog”. Essentially, this is a task list that’s ordered from highest to lowest priority, and might be broken up by cut lines for sprints or version releases. The flat backlog is simple (it’s basically a to-do list) but if you have a complex product, lots of teams working on it, dependencies, and a massive, ever-changing backlog… you’re going to need something more robust so that you don’t lose sight of your goals, customer-focus, and priorities.

Speaking of alternatives, check out this little story from one of our customers…

What user story mapping can do for teams

"Our teams were looking for an alternative view to the standard Jira backlog/board view, which doesn't lend itself to organizing and grooming massive backlogs with lots of epics.

The Easy Agile User Story Maps app allows our teams to better organize their work. The user interface is logical, and product owners (who are usually non-technical folk) like the layout of cards in columns under their respective epics.

This vertical view seems to foster better communication doing planning meetings and does a great job of providing a visualization of what comes next."

- Christopher Heritage, The Atlassian Team @NextEra Energy

So, as you can see from this example, a lot of teams start with flat backlogs or board views, but find that they outgrow this as their backlog gets bigger.

How user story mapping can upgrade your flat backlog

What makes user story mapping different from the flat backlog is that it has a whole other element. It’s not flat, but more three-dimensional.

You’ve got the list of activities/tasks, but they’re first sorted by how they impact the customer journey. Only then are they prioritized and broken up by when they’re being released.

User story mapping is a little more complex to set up than the flat backlog, but it makes the work more meaningful, customer-focused, and impactful. With a user story map, you can see the big picture and collaborate on it.

We talk more about this in our blog, The difference between a flat product backlog and a user story map.

Try user story mapping inside Jira

Want to know the best way to understand what user story mapping is?

You can’t learn how to ride a bike by reading about it. And you can’t *really* learn what user story mapping is without doing it and experiencing the benefits firsthand.

So, give it a try!

If your team uses Jira for project management and workflows, you can get an add-on that helps you turn that flat backlog into a three dimensional user story map.

Easy Agile User Story Maps for Jira creates the X-axis so you can add your customer journey backbone and organize your stories to fit into this journey. That way, your team gets the big-picture view of what they’re working on, and they can prioritize tasks to deliver maximum value to your customers, sooner.

Best of all, you can do all your user story mapping inside of Jira so that it’s digital, collaborative, and constantly available to your team - even if they’re working remote/distributed. And since it fits in with your existing backlog, you can hit the ground running with pre-filled user stories. In other words, you can expect to save a whole bunch of time.

You can get started with Easy Agile User Story Maps for Jira, with a FREE 30-day trial today or check out the demo here.

Try now

Hopefully, you’ll find it just as useful as our customers…

We’ve found that Easy Agile User Story Maps brings the team together in one room. As a result, we find ourselves mapping more as a group, which creates a common understanding. Since using the add-on, we’ve been able to speed up planning and more efficiently conduct large story mapping exercises.

- Mike Doolittle, Product Director @Priceline

Since using Easy Agile User Story Maps, we’ve improved our communication and team alignment, which has helped give us faster results.

- Casey Flynn, Distribution Forecast Analyst @adidas

Easy Agile User Story Maps has helped us visualize our workload and goals, as well as speed up our meetings. We love the simplicity!

- Rafal Zydek, Atlassian Jira and Confluence Expert Administrator @ING Tech Poland

With Easy Agile User Story Maps, we find it much easier to use and navigate Jira. Our favorite features include the ability to drag and drop stories across the Epics, being able to view the work using FixVersion and Sprint Swim Lanes, and Excel export. We’ve been using Story Maps functionality for quite sometime now and I recommend it to other project teams, as well.

- Sathish K Mohanraj, Lean-Agile Coach @Equifax

Learn more about user story mapping

Want to learn more about user story mapping? Check out our User story mapping ultimate guide - it has everything (and we mean everything) you could possibly want to know.

We’re always happy to answer your questions. Just send us a tweet @EasyAgile or contact us if you’re not sure about what user story mapping is, how to do it, or how it could help your team.

What is User Story Mapping? And more importantly, WHY would you want to run a story mapping session with your team?

Let’s start off by talking about the origins of User Story Mapping.

It’s now a common practice in agile software development, but it wasn’t always that way.

If you have experience with a Scrum or Kanban backlog, you've likely run into the dreaded flat backlog.

Why Story Mapping

In its simplest form, a flat product backlog is a laundry list of stuff 'to do' that will ultimately provide some form of value to your users/customers. At least we hope so.

Many of us have contributed to making these backlogs longer and longer, and they inevitably become overwhelming.

Regardless of whether the team pulls work from the backlog one-by-one or groups it into sprints, prioritizing work in a flat backlog comes with its challenges.

The flat backlog is a 2 dimensional view. It’s like a shopping list, which doesn’t provide context for the work.

Enter, the User Story Map! The concept of a User Story Map was born out of a desire to kill the flat backlog and create a more holistic, customer centric overview of our work.

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.

Usually conducted at the beginning of a Project, a user story mapping session is done with the sole purpose of creating a shared understanding amongst the team of who your customers are and how you should focus your time working on stories that provide the most value for them.

You can do this on a whiteboard with sticky notes, or you can do it in Jira using our app, Easy Agile TeamRhythm.

How to build a user story map

To create a visualisation of the journey a customer takes with a product, start by identifying each stage, and then list the activities and tasks the customer would typically complete for each.

Next, begin to associate each item of work in the backlog with its corresponding touchpoint in the customer journey.

At this point in a User Story Mapping session, a matrix should begin to emerge, containing a list of tasks or stories to which the team has committed to delivering, organized according to the steps in the customer journey.

From there, the map is divided into the time blocks the team uses to plan their work. For example, in sprint 1, the team might commit to 5 user stories, which are attached to 3 epics.

This helps build understanding of how progress will be made against larger pieces of work.

Why user story mapping is better than a flat backlog

Connecting the work in the backlog to the customer journey in this way begins to answer key questions like:

• WHY are we building this?
• WHO are we building this for?
• WHAT value will it provide them?
• WHEN do we expect to deliver this?

User story mapping essentially converts the 2D flat backlog in a three-dimensional view, because it gives us a way to say, “ok I’m currently working on building this user story, and I can visualise what piece of the customer journey this will be directly impacting AND we know when it will be delivered.”

Also, by putting the focus on the user, a story map ensures that the backlog contains work that add real value for the customer by helping them achieve their goals.

How to run a user story mapping session

Now that you have a better understanding of the value of a User Story Map, let's look at how to create one. First, you’ll need to set up a Story Mapping session with your team.

But whatever you do, don’t make it an open invite. This is really important, because if you don’t have the right people in the room then it won’t be effective.

People you could consider inviting are:

The product owner for the team

• a tech lead
• a user experience designer
• a marketing lead
• a data analyst and,
• someone from customer support

It’s also important to set some ground rules for the session.

There should be one person facilitating the session. A good practice is to involve a Product Manager from another team to run the session.

Depending on the scope of the story mapping session you may want to take a whole day or spread it out over a couple of days.

The scope all depends on how big your team is and how many user stories you need to add to your map.

There should be no phones or laptops out except for the facilitator.

Also, everyone in the room should be familiar with the user stories being discussed.

Now that you know the benefits of a user story map and what to consider when setting up the mapping session with your team, start thinking about who you can invite to participate in and facilitate the session.

Atlassian alumni make up a part of the Easy Agile team, with several former Atlassian staff working within the Easy Agile business. We had a chance to speak to another member of this extended alumni ‘family’,  Boris Berenberg. Boris is an ex-Atlassian who eventually went on to found the New York HQ Atlassian Solution Partner Atlas Authority.

It was a particularly exciting day for us to catch up with Boris, as after a mere 3 1/2 years, Atlas Authority achieved Gold Partner status with Atlassian.

Personally, I had the pleasure of working just metres away from Boris in the San Francisco office. It was great to hear his journey, and learn how the Atlas Authority team have grown to double-digit staff members based in multiple countries in such a short amount of time. Meet Atlas Authority, an Easy Agile Partner.

How did you end up working for Atlassian?

I found Atlassian because a friend that I went to college with told me about this company that he was working for that paid to send him to Amsterdam for three months. And I thought that sounded cool. So this ‘perk’ was the driver for me getting into it.

An obscure way to ‘find Jira’!

Well, I started my in-depth learning of Jira at Atlassian because I helped write a lot of the performance tuning documentation when I was there. A lot of this work was done by the Sydney support team and I ended up dealing with most of the performance-related tickets that were coming into the San Francisco office at the time.

So when I left Atlassian, my particular skill set that very few other people had was, how do you make your Jira faster?

How do you get a performance improvement on Jira?  That was my expertise.

So after Atlassian, you started Atlas Authority?

I needed something after Atlassian and I went to work for another company.  During the interview process I recommended they look for a  contractor for a few months but they still felt the role required a full-time staff member. So I joined them. It was a great job and a great team. Three months in, I was sitting there with nothing to do, kind of like I had predicted. So I went to the CTO, who was my boss at the time, and I said, look, my number one mandate has been to reduce Atlassian spending at this point. I'm going to go work somewhere else and wishing you guys the best of luck.

And at that point, I went to go work at Uber, and Uber was probably the best team I've ever worked on in my life. We're working with one of the largest Atlassian deployments in the world at the time; we were just all on the same page. Having that level of understanding and shared expectations on a team was just out of this world.

So because of my tenure at Uber, I had some ideas at the time around how an Atlassian practice should be run and I started Atlas Authority to see if my ideas were right or wrong. If my ideas turned out to be right to some subset of the market, then we could be a successful company.

I guess three and a half years later, we are. We are now almost 10 people in 3 countries.

So would you class your expertise as being Atlassian application performance focussed today?

Well we used to focus specifically on that, for instance, we helped the largest telco in America reduce their average Jira page load time from 12 seconds to 4.5 seconds. So a huge improvement.

At the same time, whilst our business grew, Atlassian was doing a really great job of improving the performance and stability of Data Center deployments, and they've done a really great job in Jira 8.0 around indexing performance. If you monitor Jira releases, you'll see that there's a pretty steady stream of performance-related and scale-related issues being resolved.

We knew that we couldn't continue to focus on that. We've kind of become a more general Atlassian partner at this point. We still tend to work with very large Data Center deployments with people doing highly technical implementations that involve very heavy, hands-on analysis, or writing custom code. We do data transformations from migrations from and to the cloud. We help with plugin migrations. Still very complex problems, but different from where we started.

Today, we also have a portfolio of 13 Atlassian Marketplace apps we call our own.

Were these marketplace applications from customer needs?

We created Atlas Authority’s marketplace business in a couple of different ways. Atlassian has a regular event called Ship It. Back in the day when I first joined, the support team was notorious for not participating in these events because while everyone else can stop doing their jobs for 24 hours, the support team found it hard to participate because they had to respond to customers. So I did my best to participate.

I created the Markdown Macro app and took second or third place for that Add-on during the ShipIt. And I won a ticket to the Dropbox developer conference at the time when the Developer Relations team picked me as their winner.

When we got started with Atlas Authority, Atlassian actually granted us the ability to continue to manage that plugin. And so at this point, it's grown to about 5000 installations and millions of end users. We push updates to it regularly & it started our journey into the Atlassian Marketplace.

Which add-on do you think solves the biggest problem?

Our customers are predominantly large organizations. Communicating within them is tough. For instance, people will say, “Hey, you know, my CTO doesn't understand the work that we do in Jira. If we purchase a reporting plugin, it may serve that information up better”. The thing is, a CTO doesn't want to go to Jira in the first place.

Most CTO’s sit in twelve meetings a day and make technical decisions. There’s not a lot of time to go digging through a tool. So providing a Monday morning email that summarizes exactly what's going on in the various initiatives automates updates and improves communication.

It means that you can bring the right message, in the right format, to the right person, at the right time.

The ‘push’ nature and the ubiquity of email makes our Notification Assistant for Jira a real elegant solution.

Does Atlas Authority use Agile methodologies to run the business?

I have had an interesting journey with Agile because when I was working at Atlassian, I built a tool using my 20 percent time. The tool did great, but the project completely failed because we hit the goals of the finance team and not the support team that was paying for the work that we were doing. So classic project failure scenario. A really hard lesson, and a reminder why a core tenant of Agile is to ensure your stakeholders are involved in what you’re building.

Now in the consulting world and owning our own products, we deal with Agile constantly, both in a delivery capacity as well as an internal capacity. Internally, we happen to use Scrum for a lot of the software development work we do. We heavily utilize Kanban on the support side.

So that was how you ran into Easy Agile products?

We were essentially using Easy Agile Roadmaps for two things. Our product development org is a bit scrum-fall. A portion of waterfall at a high level. Similar to program level planning, or doing theme or initiative level planning, but using a roadmap. And then we break it down as we get close to it and use a more traditional methodology to accomplish that.

On the other side, we were also using Easy Agile Roadmaps as a tool to visualize our consulting engagement work. As a way of seeing which customer engagements are running in parallel and what resources are associated with those customer engagements.

If we have a person working part time on a  customer migration, and that migration is going to take three months, we need to be able to visualize that. We needed a light-weight tool that could deliver this for us at that time.

So you use Easy Agile Roadmaps to run your business! We are honoured. Have you encountered us at any customer sites?

We do, but we don't notice them for all of the right reasons!

We resell a lot of plugins, and a strong statement of support of Easy Agile’s tools is they work so well that we don't have to do very much handholding of customers. We don't have to do a ton of training. The UX is done really well. The visual design is done in such a way that it fits into the narrative of Jira as visual design. So a user doesn't need to learn a new visual terminology.

From a performance perspective, from some other vendors, we may see obscure issues. For instance, when we may see a background synchronization job running and it’s causing everything to slow down. Another common issue that we see is that large organizations tend to have similar time-based patterns of plugin usage when it comes using these tools. Another example is when everybody across the organization does their P.I. planning on the same day at roughly the same time.

If that tool is not built in such a way that takes into account this parallelism you can encounter serious problems when people are depending on the product. A lot of the time an application may have low usage 90 percent of the time. And then 10 per cent you will encounter crazy spikes in terms of what that application is asking Jira's backend to do which can make it all fall over.

I don't think we've had to deal with a single complaint about Easy Agile apps in three and a half years of consulting. That's amazing.

Thanks for your time Boris, but I have to ask, did you ever get to Amsterdam?

So that's a great question. So during my interview with Atlassian, they asked me why I applied. I mentioned the secondment was a common thing I heard about the company. They said, absolutely, you can do that with us. I should have gotten it in writing as it took over 3 years to get there!

But it was worth it the wait, I had an amazing time. I loved Amsterdam and I've gotten back five or six times since then.

It's been one of my favourite cities in the world that I've ever gone to and I particularly enjoyed working with the team there.

Atlassian Authority has been acquired by Modus Create.

Need help? Get in touch with Modus Create or follow them on Twitter, LinkedIn or Facebook.

I fell into web development, that's how it feels without digging into the details. That does not sound like how you want to go about choosing a career but in reality, it was years of small decisions and nudges that I ended up doing work I really enjoy.

I grew up enjoying all things computers, but let's be honest it was mostly video games. In high school, I took all of the subjects available that had anything to do with computing, except for the software development subject ironically. I think because I didn't know about the potential creative side, I thought it was all hard maths. There was a subject I did where my major project was a batman flash animation, I was motivated in that class -- while others might have been bludging off and playing flash games, I was focused on making my flash animation and enjoying every minute of it.

Then it came time to do something after high school. I still didn't have a good idea of what I wanted to do so I choose a broad degree that involved computers — Information Technology at UOW. It was a mandatory programming subject in that degree that gave me a taste of software development, it involved building programs where the output was just in the terminal which didn't excite me much.

Then came a subject that everything started clicking together, Web Programming -- I think it was called. It combined design and code, used some newer web technologies, and was taught by lecturers who were clearly passionate about the web. We did projects like redesigning the movies page and I loved it. It also gave me a taste of making something that was useful, other programming subjects I did previously were just about outputting lines to the console.

After this experience it still didn't occur to me that I could get a job doing this, I didn't know anyone that was doing web development as a job. So after university, I went on a month-long holiday and tried not to think about what I was going to do when I got back.

When I got back I started applying for jobs, and a few of them for this role called frontend developer which was a new term to me. It was in the process of doing the take-home projects that I was given as part of the interview processes that I realised I could get a job in this thing I enjoyed.

It's been around 5 years since then and time has gone fast. In that time I was thrown into the deep end of many projects and have always finished them with more knowledge than when I started. Thanks to both the talented people that I have worked with and the challenge of the projects themselves.

I'm looking forward to the next chapter here at Easy Agile!

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 🤞