Do you know your customers? As in, really know them?

🥞 What do they eat for breakfast?

😎 Who’s their favourite James Bond villain?

🛁 Do they shower in the morning or at night?

Okay, so you don’t have to get that creepy…

But you do need to know a lot about the customers you’re developing products for. Otherwise, the features you’re working on might not be useful or valuable.

This is pretty important stuff, so let’s take a look at 7 reasons why it’s good to have a healthy level of customer obsession in your agile teams...

1. Agile and customer focus go hand-in-hand

Agile is all about the customer. At least, it should be.

It’s right there in the first two agile principles:

(1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

You can’t really call yourselves agile unless you put your customers at the centre of what you’re doing.

2. Each sprint should deliver a better product for your customers

One reason why agile should (🤞 in theory - we’ll expand on this shortly) benefit your customers is that every two to four weeks, your users will usually get new features and upgraded products.

This is kind of a big deal when you compare it to traditional project management approaches.

Pre-agile, customers could be waiting many months or even years before they would see any changes. In many cases, by the time updates were released, customers, technologies, and requirements had moved on.

But when you’re agile, it means that:

• Your customers can request updates, features, and changes at any time
• Users should potentially see new features added to a roadmap and rolled out in weeks or months, not years.
• If something’s not working, your customers can report the issue and provide feedback right away
• Users can see how the product is developing and growing
• Your product is moving forward and the customer is moving forward with it
• The product becomes more valuable to your customers over time

… but it’s important to note that all of these really awesome benefits only really apply if you’re prioritising your backlog and choosing features with your customers’ best interests at heart 💞

3. Agile teams need to know what’s valuable to their customers

As we’ve talked about previously, “there is a chasm between the output of a team and successful outcomes for their customers. And the success of a team is measured by outcomes, not code.”

Fact is, your customers have different priorities to your developers.

Your developers likely want to work on projects that they find exciting or fulfilling. But the best agile teams know they need to prioritise the features that matter to their customers. Because if you’re not solving their most important problems, your customers will find someone else who will solve them 😨

4. Customer focus leads to better quality products

When you’re obsessed with your customers, you deliver products that actually matter.

One study found that “quality is influenced by top management’s commitment through customer focus”.

And this makes sense - if your team stays focused on your customers, there’s a much better chance that they’ll build the right things at the right time for the right people. And this is critical to the success of your product and organisation.

It’s also a great way to avoid building bloated products with unnecessary features.

5. Do better planning and prioritising

Your backlog shouldn’t simply be a to-do list. It needs to include feedback from your customers and attempt to tackle their greatest pain points.

Program Increment (PI) Planning in scaled agile relies on a healthy customer obsession to inform your product requirements.

During PI Planning, you’ll discuss the backlog with other teams in your Agile Release Train (ART), prioritise your features, and schedule work for the upcoming iterations.

Without a solid understanding of your customers to inform your backlog, you could end up planning an entire increment that doesn’t deliver anything useful or move the product forward for users. And that’s a pretty costly risk, if you ask us.

6. Do everything better with customer feedback

Teams who are obsessed with customers love getting customer feedback, whether it’s via customer interviews, surveys or just having a chat about their experience 🤓

Customer feedback is incredibly powerful because it can help you:

• Understand your customers - Know what their biggest problems are and what they care about most
• Motivate your agile team - Help your team understand the problems they’re solving, the difference they’re making, and that their work is meaningful
• Spot trends and patterns - Ensure your product adapts to what’s in demand right now and what your customers will need in the future
• Make better products - Find out what’s not working so you can fix it
• Track your progress - See whether customers are happier with your product over time
• Stay relevant - Because products and companies that solve problems stick around long-term
• Get buy in - When your customers are involved in the process, they’ll feel more committed to the product, which can reduce churn
• Improve retention - Reduce churn and keep your customers for longer when you incorporate their feedback and ideas into your product
• Make data-informed decisions - Stop relying on your assumptions and let the data drive your strategy

So customer feedback is obviously awesome, but what do you actually DO with it? How do you share it with the team and turn it into actions? Well, that’s where user story mapping comes in.

7. Agile user story mapping is all about the customer

Most agile teams run user story mapping sessions to discuss what functions and features are needed in the product. User stories are a visual tool for customer focused development, ensuring your customer journey stays front and center throughout development.

This is where customer feedback comes into play. When your team can access a wealth of feedback from users, they can write user stories informed by real data. This gives them a much better chance of prioritizing features that will add value to users right away. And it means they’ll always know what features to work on next.

Plus, it makes it much simpler for your team to reach a consensus, compared to your team of developers butting heads about which features they think should be prioritised 😬💥

By the way, one of the best ways to help your team be more user-focused is to help them streamline the way they do user story mapping 👇

So, if the paper and sticky notes approach isn’t working for you, try a digital user story mapping tool like Easy Agile TeamRhythm.

Simply enter your stories, click and drag to move them around, organise horizontally and vertically, and arrange stories into sprint and version swimlanes. Plus, the Jira integration means that any changes are automatically saved in Jira so that your team can get straight to work.

Sign up for a free 30-day trial of Easy Agile TeamRhythm and let us know what you think!

Being more customer-focused is a solid strategy.

If your team isn’t exactly obsessed with your customers, maybe it’s time to change that?

Because at the end of the day, if you’re focusing on your customers, you’ll make more of the right decisions about what products, features, and requirements you need to work on. Which means your team will find it easier to make decisions, you’ll waste less time, your users will stay loyal, and you’ll build a better product that gets better all the time.

It’s a solid strategy. Everybody wins! 🎉

Earlier this year on a call with Michael Dockery, Chief Strategist of Design Industries (DI) in Melbourne, Australia, I asked: "What could we do better?"

Michael said, "...a way for vendors that worked with us to improve the way partnerships are promoted."

With that suggestion, the Easy Agile Meet the Partner interview series was born. Fittingly, our first interview is with the company that suggested the initiative.

Design Industries are obsessed with improving the productivity of their Enterprise & Government clients. They do this by optimising their clients' usage of Atlassian tools and implementing best practices while ensuring the platform and apps remain highly available through their partnerships with AWS and Ali Cloud.

Here is a conversation we had with Michael, Philip (Marketing & Comms Director) and Alice (Executive Business Partner). We discussed who they are and what they do, including some common IT acronyms you can learn about if you look them up :)

How did you encounter the Atlassian Platform?

Michael: Design Industries started as a web development company. We were doing custom code, then e-commerce content management systems, web builds, startup consulting, custom API mapping - all sorts of stuff! We took up Atlassian for our service delivery as we were using SVN, I think it was Base Camp, and other tools at the time. We knew we needed something else. I looked at lots of platforms for years and was looking at every project management tool out there.

I noticed Jira and thought that it looks complicated, a bit overwhelming, and then I saw the price - this was when Atlassian released their software as a service product - $10 for ten users! Everything else was $160 per user per month, so we took it up, and in hindsight that was a great decision.

And where is the Design Industries business today?

Michael: We're now half in Melbourne, half in Cebu in the Philippines. We support clients across Australia and help them to make the most of the Atlassian stack. Most of what we do is assisting around project management solutions, so organisations come to us and say, "We want to use Atlassian," or, "We are using Atlassian for project management, can you help us?" And the primary use case is around ITSM (IT Service Management), where they want to run some type of ITIL practice, so we help out with that.

There are also a lot of custom scenarios: a marketing, finance or HR team wanting to improve their workflows. What we've done is created predefined configuration sets for all those different types of operational core competencies to solve their recurring challenges.

Essentially we help organisations fast-start their practice or give a quick uplift to their capabilities by implementing these predefined configuration sets. This is how we support leading companies to make the most out of the Atlassian Enterprise stack. The next step is not only to support the platform and enhance its capability: it's being able to do that on a continual basis - which is where we are leading the market.

What we do with a lot of our clients is continually deliver improvements to the platforms: whether that's improvements in configurations or reporting; additional plugins; retiring other software platforms in the environment; onboarding teams and functions; integration with other platforms and applications in the background.

Are there any notable customer projects that you could mention?

Michael: There are quite a few listed on our website. We helped a significant retailer move onto the Atlassian platform as a core operations piece, assisting them in standing up their Atlassian Data Center environment. We put our standardised configurations for project management in and then we migrated their disparate platforms onto a primary enterprise instance. They were able to standardise and consolidate their Atlassian instances, so that was pretty cool!

Then there was another notable sizeable financial company. Again, Design Industries helped them stand up an Atlassian stack with our predefined configuration sets and, this time, in our managed AWS service. We then took the encrypted data from their parent company and imported it into this new environment. It has now grown to be the enterprise stack — their core delivery platform.

Philip: Each time another major company comes to us, it helps build our pool of knowledge. We often hear customers saying, "Wow! What, you mean you can press a button stand up an Atlassian instance? And then we have enterprise maturity as a scalable framework?"

We respond with, "Yeah, that's what we sell here. We give you a step-change in your organisational efficiency."

Where do you see common pitfalls occur when a customer begins deploying Atlassian tools?

Michael: That's simple — doing it yourself, giving too much Administration rights to people who aren't trained, aren't qualified and implementing it in an ungoverned way. That's a big mistake! However, I've seen it work as a change strategy. You know you can't make such a massive change without allowing people to do it themselves. So throw it over the fence go "OK, here is the tool, run with it" and then hope that the users get excited. When they get excited, then come back and retrofit the policy and do the cleanup, put the process on top and then retrain everyone.

If you've worked in IT or change management before, I'm sure you would agree taking that strategy is a costly mistake. It's better to do it the right way from day one and govern it with a vision in mind. It's an enterprise platform, not an insignificant piece. What part of "mission-critical" don't people understand?

Amongst the Atlassian ecosystem, is there anything that excites you as being "the future"?

Philip: Automated test cases!

Michael: What excites is it's pretty unlimited what we can do, and the capabilities are going to increase. I can see how this platform is beautifully set for some future trends, particularly around automation. I'm just excited that there's so much to do in this space. There are so many businesses that could use the capability that the platform can bring, and most - even if they've already got it - are barely scratching the sides of what's possible. We could close the doors for six months and work on ourselves and our processes!

Philip: Two years ago, we were having conversations about the massive efficiency that could be gained in government by taking on more Agile Project Management. There is so much waste that goes along with poorly managed projects and the associated rework. Then there are things like responding to natural disasters, where you can stand up a fit-for-purpose project management environment, notify the relevant people, get co-ordinating and deliver change on the ground.

Michael: Automated responses to predefined plan execution. I can think of so many things!

So when it comes to Agile, where are your customers these days?

Michael: What is interesting with Agile is the world has turned. I think everyone is now somewhere in the Agile journey, and that has changed from a few years ago. I guess the approach and the degrees of success vary significantly between our clients. Walking into offices, I still see many wallboards and sticky notes. There is always room for improvement.

The journey has begun. Some are doing it well; most can improve; everyone is in the middle. It's interesting times in the space.

There's the opportunity to optimise Agile processes everywhere!

Michael: I think it's just hard! I read about what they call "zero budgeting", which is a method to do budget allocation for Agile projects.

That is such a massive shift in how projects get funded and defunded. If you're going to sit there and say, "OK, we want to measure the value that's being returned on a live basis so that we can fund and defund on an agile basis," you've got to have the tooling in place. If you can't do proper portfolio reporting, you can't tell me what all of your initiatives are.

That means you have to have some type of standardisation in the delivery tool and in the portfolio. You can sit there and go, "OK, I can see my initiatives. I can see what's delivering value. I'm now going to make a monthly budget decision."

So it gets away from these big projects, where most of the C-Level still operates, to where they make funding decisions once a month. These decisions are much smaller, and they're based on who's doing well.

With Agile, there are different interpretations and you've seen different maturity levels in organisations. What resources do you provide to customers? How do you help them find clarity?

Michael: In terms of resources, I used to buy a book called The Lean Startup and give it away like crazy. So that teaches you Lean and Agile, and I think people need to go through the Agile "light bulb" moment. I very distinctly remember when I had my light bulb moment with Agile - there was a before and after. Before, it was confusion, and after, "Aha! I understand this now!" I still think that goes on for a lot of people.

The other one is Lean, and I think that's part of the Agile "light bulb" thing. As a senior stakeholder, you want to achieve things; you're going to invest in things. But having an understanding of what a lean approach looks like, and how a lean approach can be executed, helps a senior executive who typically won't have the time to go out to Agile training. It helps them get a sense of how to structure work, make it small, deliver some value.

The Lean Startup book was what you used to advise before. What do you do now?

Michael: * jokingly * I tell people to get the book!

In all seriousness, there are a couple of principles that you need to understand, and they are similar but different. Waterfall has milestones, Agile has a release. Waterfall has a week of work, Agile has a sprint which you set yourself. For example, a sprint may be one, two or three weeks - we use weekly. You get up on a Monday and say "What are we delivering this week?"

The benefit of Agile is delivering value fast and getting feedback fast, to inform your next delivery. In Waterfall, you're following a predetermined plan that is resistant to change. I like to think of it is as "What are we doing this week?" in Waterfall and "What are we delivering this week?" in Agile.

Lean-Agile is the next step, coupling lean principles to Agile methodology. It's well worth understanding if you're looking to the future. The Lean Startup, it's a classic. People ask, "How do you start a business? What's the most you need?" The most you need is literally a piece of paper and a pencil, and he gives examples of this. You can then say "I don't need $100k to start a business. I need a piece of paper and a pencil." It becomes a lot more achievable.

With these lean startup principles, what have you seen in large enterprise or government that has been successfully deployed?

Michael: They will talk about it in The Lean Startup and call it a "Tiger Team", and that's how most organisations have ended up doing it. Find a team that is a bit more innovative, a bit more flexible and seed the practice. Then with executive support, go, "OK, we're going to change the methodology. How do we do this? How do we find a team who's up to it?" You then get them trained, get them implemented, get the process sorted, get a best practice approach, you roadshow it and roll it out to the organisation. I think that's happened for the executives that have decided to go to Agile. The rest are just fumbling through at the moment.

Where do they need help if they're fumbling through?

Michael: More of a realisation that the toolchain is really important. Agile means you still need to have a written process. You need to have an elaborated work breakdown structure, and make it clear to the team how they're going to break up the work and put it through the system, even though they're "Agile". It still requires a project management configuration and then portfolio reporting.

If you've got the teams running their own processes, it's highly ineffective. We see divisions such as, "Team A are using Story Points, Team B use Estimation, Team C use nothing... and Team D, well, they kind of do it their own way - I think they're Waterfall". What a mess!

The whole process requires someone responsible. Most organisations have this initiative going on called "digital transformation". It requires an individual who is in charge of digital transformation to be able to make decisions on methodology when it comes to project management and how that interrelates with the tooling.

Philip: I think of it like showing senior executives fire for the first time. They haven't ever had reporting down to the level we are talking about once you've got the bottom up using this toolset. Previously, the reporting culture was, "Can you provide us with five slides for the senior exec or the board pitch?" where now it comes to, "Well, you can report on everything now at the click of a button and you can see it in real-time."

So it empowers at the top level, and it frees people up to work on high-value tasks.

You mentioned Eric Ries with The Lean Startup. Any other thought leaders that you follow?

Michael: *laughing* McLaren.

Philip: Michael's obsessed with Formula 1. It's a bit of a driving force behind how we do things here.

Michael: Formula 1 certainly is an interesting analogy. I don't know if it is in terms of thought leaders, but in terms of an area of inspiration, definitely Formula 1 and how it works because there's a lot to it. It's teamwork.

It's high-performance teams, high-performance machines. I look at the way we configured the tooling, and it's our high-performance machine.

It's probably not as exciting as a Formula 1 car, but it's what we've got, and we certainly get to drive it - but it's not as dangerous either!

We know you love Easy Agile apps. Any other Atlassian Marketplace apps you love recommending?

Michael:Riada Insight Asset Management is really powerful. For a lot of organisations when it comes to ITSM tooling, the monitoring tooling, the asset management tooling, and the ticketing tooling aren't integrated. It is quite tangled. So when an organisation is looking at Jira Service Desk, it's a no brainer.

Then there is Tempo Time Tracking. When one of our clients want to bill their clients, or they need to manage their budgets effectively, it works perfectly. It also lends towards capacity management. A lot of organisations struggle with their capacity management. Using that suite makes it super easy.

Lastly, if a customer would ever like to get in touch, what's the best way?

Philip: They call us at 1300 736 363. They can also fill out a contact form on our website. The form gets responded to quickly. We generally respond within an hour. We usually then book in a call. If it is a relatively straightforward request, we can get a proposal back within 12-24 hours.

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.

Ceremonies are regular events held by Scrum teams. ‘Agile’ is a broad word describing a different way of working with shorter, time-boxed cycles for releases.

Under the broad umbrella of agile, Scrum is one of the most popular approaches that teams use to organise their work and releases.

Each short iteration of work in Scrum is referred to as a sprint. A sprint is normally a 2 week period where the team focuses on a small slice of work.

The idea is that everyone focuses on 1 slice of work. And that slice is to be completed and shipped to the customer within that same sprint.

Scrum can be broken down into a few important elements:

1. Roles
2. Artifacts
3. Ceremonies

This post will focus on the Scrum Ceremonies.

All of the 4 Scrum ceremonies help ensure the Scrum team stay focused on the slice of work they agreed to focus on in that sprint.

It helps the team with transparency about progress on the work they committed to finish and to raise any issues early before they become blockers.

Let’s have a look at each of the four agile ceremonies in Scrum:

1. Stand up (or daily Scrum)

Goal of the stand up: a brief check-in where the team can raise issues or communicate with the whole team face to face.

Who joins the daily stand up: Developers, Scrum Master, Product Owner

Outcome of daily stand up: the team raises any blockers, but doesn’t have to solve them. Ensure each team member is clear about what they are working on. Each team member should be able to answer these three questions:

• What did I complete yesterday?
• What will I work on today?
• Am I blocked by anything?

When to hold a stand up: daily

Tip: stand ups can be done by business teams and don’t always have to be face-to-face. Here’s a photo of Australian bank ANZ’s executive stand up in action:

And another pic from InsideIT’s stand up:

2. Sprint Planning

Goal of sprint planning: sprint planning helps the team prepare for what work is coming up next. The team discusses each item of work which has been prioritised by the Product Owner.

Who does sprint planning: Developers, Product Owner, Scrum Master

Outcome of sprint planning: that everyone knows what the sprint goal is and how they are going to achieve it. Make sure everyone understands what’s the overall vision or objective of the work.

The team will be comfortable with what work is available to be picked up in the next sprint. The team will discuss any impediments or opportunities and how they can optimise the way the work will be completed.

The team will also estimate the work and draw a line when it is estimated that the effort to complete the work exceeds the team’s capacity or historical velocity.

When to hold sprint planning: at the end of a sprint or very beginning of a new sprint.

Bonus: sometimes in sprint planning you will find things you won’t do, and that’s valuable too.

3. Sprint review

Goal of the sprint review: showcase the work completed and receive feedback from the Product Owner and relevant stakeholders.

Who joins the sprint review: Executive Sponsors, Developers, Scrum Master, Product Owner

Outcome of the sprint review: each team member feels empowered by showcasing their work to the team. The team can celebrate their achievements. Executive team can ask questions. Product owner can provide feedback and check the work is of high quality and satisfies the user story. Works best with drinks and cake.

When to hold a sprint review: at the end of each sprint.

4. Retrospective

Goal of the retrospective: honest discussion about what worked well and didn’t work well. Encourage self-improvement and transparency.

Who joins the retrospective: Developers, Scrum Master, Product Owner

Outcome of a retrospective: receive feedback from the team and seek to improve in the following sprint. The beauty of agile and Scrum is the fast feedback loop.

If something isn’t working well, it only hurts the team for a maximum of 2 weeks. It can then be addressed at the retrospective and action can be taken to address the issue before it gets out of hand.

The outcome should be a commitment from the team to focus on addressing areas that need improvement or continuing behaviours that benefit team health and/or velocity.

When to hold a retrospective: at the beginning of a new sprint, reflecting on a sprint that has just ended.

---

The common theme across these Scrum ceremonies is that they encourage team collaboration, transparency and communication.

In my experience, this is what truly makes agile a better way of working.

It’s not the story points or even the way the backlog is prioritised that makes a difference. The true game-changer of agile is that it helps teams with open and honest communication.

These agile/Scrum ceremonies won’t always work the same for every team.

However, they are a great way to facilitate conversation and encourage continuous improvement.

It’s one of the most common practices in agile software development; the flat product backlog. We’ve all seen them, we’ve all contributed to them, and we’ve all inevitably drowned in them.

In its simplest form, a flat product backlog is a laundry list of ‘stuff to do’ that will ultimately provide value to the customer. These actionable items are prioritised (top to bottom) in the order the value will be delivered. If a team is adopting the Scrum method the backlog is split into future sprints to provide an indication of what will be delivered and when.

Depending on the size and requirements of the organisation, the list of things to be done could be 10, 100 or 1,000 actionable items. It’s easy to see how managing the latter comes with the challenges of updating, assigning, grooming and scheduling these items.

What’s Wrong With Flat User Story Backlogs?

So far we know that flat backlogs represent a list of things to be done. This comes with its challenges, and its shortcomings were best described by Jeff Patton when he said;

We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.



After all that work, after establishing all that shared understanding, I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree.



That’s what a flat backlog is to me. A bag of context-free mulch

How do you pick an item from a list, and deem it the thing that’s going to provide the most value to your customers, without that additional context?

Shortcomings of a Flat Product Backlog

• The flat backlog makes it impossible to discover the ‘backbone’ of your product — the customers interaction experience with the product
• Arranging user stories in the order they’ll be delivered doesn’t help a product manager explain to others what the system does
• The flat backlog provides no context or ‘big picture’ around the work a team is doing
• A flat backlog makes it hard for the product manager to determine if they’ve identified the relevant user stories
• Release planning is difficult with a flat backlog. How do you prioritise what to build first in an endless laundry list?

User Story Maps

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

It provides context for teams by answering the following questions:

• Why are we building this?
• Who are we building this for?
• What value will the solution provide for the customer and when?

The story map still showcases the ‘stuff to be done’, the difference here though, is the way in which this information is visualised. As you can see, rather than listing these items out, each item is contextualised under a bigger piece of work. Besides the way the information is visualised, the key difference between a flat product backlog and a user story map, is the focus on the customer journey. Let’s unpack this by breaking down the anatomy of the user story map.

What A User Story Map Achieves that a Flat Product Backlog Can’t

• Focus on Desired Customer Outcomes: the visualisation of the customer journey allows teams to identify and implement features based on customer outcomes, and track progress at a glance against a story map
• Bring the Customer Journey to Life: the transformation of the flat product backlog to a customer centric story map means teams have a better understanding of their customer journey and what their customers want and value
• Prioritising Actions Based on Value to the Customer: visualisation of the customer journey allows teams to prioritise work based on “value to customer”, resulting in better outcomes and less waste

Are you getting lost in your flat product backlog? Are you stuck in an endless development cycle, but not really sure for who or why your building features?

Easy Agile TeamRhythm

Easy Agile TeamRhythm supports User Story Mapping, sprint or version planning, backlog refinement, and team retrospectives.

This past May John Walpole of Twitter presented Story Maps: A visual tool for customer focused development at the Facebook Technical Program Manager event in Silicon Valley. And our product, Easy Agile User Story Maps for JIRA, got a shoutout — thanks John!

Watch John’s lightning talk now:

John Walpole is a Technical Program Manager at Twitter in San Francisco. Prior to joining Twitter he was an engineer, product and program manager involved in the Xbox, Azure and Windows projects at Microsoft.

In this lightning talk, recorded at Facebook, John explores story maps as a way to figure out what your agile software development team should focus on (in order to satisfy customer needs). Story maps keep the customer journey front and centre during development and make it clear what should be included in a team’s sprint. For more on story mapping see Understand what your customers want with agile user story maps.