Agile transition – workshopping the roles

When going through an Agile transition, companies face all kinds of challenges. One of the biggest challenges is getting everyone on board and excited about the transition. During the transition at my previous employer in Berlin I talked to many colleagues who raised concerns. I did lots of one-to-one meetings trying to get to the root of it and I figured, that most of them were worried because they didn’t know how being Agile would change their role and responsibilities.

In this blog post, I’d like to share a method a colleague of mine introduced, which helped us to get a reluctant team on board.

In order to help them get a better understanding of the new roles, we started with a brainstorming session to identify the tasks and responsibilities of their current roles. For the sake of simplicity and easier reading, I’ve just added a few tasks per role.


Click image to view full size

The next step was to add a few columns along the top for Agile roles. We asked the team to move the index cards to the right columns without changing the the rows. This helped everyone to get a better understanding about the new roles’ responsibilities.


Click image to view full size

Some of the index cards sparked lengthy discussions so we asked the team to see if they could identify tasks that didn’t add any value. Soon enough they added another column (stop doing) for those tasks.


Click image to view full size

All team members had attended in an Agile workshop previously, so we asked them to add a few new tasks for the new roles. We added an extra row (start doing) and let the team discuss which tasks to add.


Click image to view full size

Going through this exercise didn’t answer all questions, but the team started seeing opportunities instead of being afraid to lose responsibilities. It also helped us as a transition team to bring the discussion to the teams instead of making decisions for them. They were then able to start thinking about suitable candidates for Product Owners and Scrum Masters.

For a successful successful transition it’s important to have someone with change management skills and not only focus on those who welcome change, but also include those who are more reluctant.

‘Product ownership is a team sport’

Yesterday I went to see Shane Hastie’s presentation on Product Ownership. It was interesting to meet some of Wellington’s agile coaches and I enjoyed the presentation a lot. Having said that, I was a bit surprised that some of Shane’s ideas and statements didn’t cause more controversy. Having just moved to NZ two weeks ago, I kept the questions to myself at the time, however having had a longer think about it there are some thoughts I’d like to express.

The main topic of Shane’s presentation was introducing the audience to the idea that good product ownership requires a team rather than a single person.

He started by asking the audience what they think the problems with product ownership are. I didn’t take notes, so I don’t remember all the answers, but here’s a few:

  • “Product Owner is not the Product Owner.”
  • “Product Owner is not empowered.”
  • “Product Owner is not available.”
  • “Product Owner is just a proxy for senior management.”
  • “The architecture is too complex for the Product Owner.”
  • “The Product Owner does not understand technical debt.”

I agree that some of these issues are serious and have to be dealt with. It is natural to start tinkering with the process and it’s a good thing to do. Instituting a Product Ownership team though will probably not solve the problem, but may make it worse.

I’ve seen those symptoms before and most of them were attributable to a bad or half-hearted Scrum implementation.

Shane used the backlog as an example of why he thinks one person must be overwhelmed by the role of Product Owner. He referred to the Scrum Guide where it states

“The Product Owner is the sole person responsible for managing the Product Backlog.”

The problem with this quote is that it is a bit out of context. In the next paragraph the Scrum Guide states:

“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

For the sake of the discussion I’ll ignore this part of the guide:

“The Product Owner is one person, not a committee.”

As the guide says, the PO is the one accountable for the backlog. But that doesn’t mean he/she has to do all the backlog refinement alone. I know companies who keep their backlogs completely open, so that everyone can pitch in new ideas. What the Scrum guide says though, is that one person has to be accountable. As it is the Product Owner who is responsible for the success of the product, he/she has to be the one who prioritises the stories. When in doubt which feature is more important, the Product Owner can talk to stakeholders, ask the development team for their opinion and so on.

Shane is certainly right when he says that being a good Product Owner is not easy, because you need to have a lot of skills. Here’s an overview from the presentation.

Screen Shot 2015-03-19 at 8.45.01 am

Although I agree with most of the skills listed on this slide, I don’t think that the Product Owner needs to know about UX and graphic design. I’ve seen Product Owners with UX skills spend a lot of time on upfront design instead. I’d rather let the development team figure out a good UX solution which of course requires having a UX designer in the team. Also I’ve not yet met a Product Owner with legal or compliance knowledge, but they have all managed to deliver successful products regardless.

So let’s take a closer look at what Shane proposes:

Screen Shot 2015-03-19 at 8.45.35 am

Some further thoughts I had during the presentation:

  • large management overhead
  • expensive
  • risking design by committee
  • some of the skills should be on the development team (especially UX/graphics)
  • what is the Project Manager for?
  • this resembles SAFe program layer although Shane didn’t talk about scaling
  • this will probably interfere with self-empowered teams
  • longer decision making process hence longer time to market

For me first and foremost, a good Product Owner needs a vision, good communication skills and a good understanding of his or her role and responsibilities. He/she should know whom to talk to when there are open questions and be there for the development team when they have questions. Does that mean we need a Product Ownership team? I’m not convinced.

What’s your opinion?

The joy of timeboxed meetings

I can clearly remember my first ever meeting. I was excited about being a part of it. It was an important meeting with a select group of key decision makers, business owners, major stakeholders, and me. My manager was ill that day so I was injected in to the meeting to represent the web team. I knew nothing about what we were to discuss, and certainly had no preparation time, so I was a seat filler. But still, it was a big meeting and a first for me, so I was enthusiastic even if I was little more than meeting meat.

This enthusiasm dwindled throughout the next four hours as I witnessed people discuss, as far as I could tell, nothing. Points were repeated ad nauseum, people had monologues for no apparent reason other than to be heard and discussions moved in infinite circles. By the end of the meeting absolutely nothing had been decided except than another meeting was necessary.

By the tail end of this prolonged catchup I was staring out the window feeling intense envy towards all the people I could see walking around outside unaware of the mental torture being inflicted on me in this stuffy room. They could feel the air on their cheeks, hear the birds in the trees and remember what joy was; all things that I had long forgotten.

As a result, I had come to dread meetings. But over time I found some methods of making them more productive and easier to endure.

I noticed that people’s eyes started to glaze over after the hour mark at meetings, and people were definitely mentally disengaged a half hour later. This graph demonstrates people’s attention span in the meetings:


So ensuring there is a timebox applied to each meeting is just one of the ways you can make it more concise, and therefore more productive. It also helps protect against being Colombo-ed. Anyone who remembers the legendary Colombo will also recall how he always had “just one more thing” to bring up when his interviewee thought the interrogation was over. I have seen this in meetings many times, everyone is closing notebooks, shuffling papers and generally making motions to leave, but someone decides that’s a good time to Colombo the meeting, to bring up “just one more thing”. A strict timebox gives you the opportunity to nip that in the bud, much like Norm from Cheers:


A timebox helps to minimise discussions about irrelevant topics that can often clog up an otherwise productive meetings, and helps make discussions about relevant topics more focussed. People know they have limited time, and need to make that time as valuable as possible.


When I was first introduced to Scrum I was pleased to see that each meeting had a very clear agenda. I was even more pleased to see that the four prescribed meetings were in place to help avoid other surprise meetings throughout the duration of a Sprint. I was nearly ecstatic when I saw that these meetings were all strictly timeboxed, and one of them was a mere 15 minutes long!

Going in to a Scrum meeting you know what you need to achieve and the maximum amount of time you have to achieve it. I have seen situations where teams have not gone through everything they wanted to at a meeting and felt the desire to keep going past the timebox. It’s tempting to let this happen, but calling a close to the meeting regardless of whether the team has achieved what they intended or not means that the next time the meeting rolls around, they will be more mindful of the time they have at their disposal.

Daily Standups are a great example of timeboxing in action. I have seen people sit down and get comfortable at Standups, arrive late, talk in circles, get in to too much technical detail and talk about work that is not a part of a Sprint. All of this obviously leads to a Standup that stretches far beyond it’s 15 minute timebox, and it quickly becomes a meeting that people resent attending as they know it’s going to carry on for an undetermined length. But if you cut it off at the 15 minute mark regardless of what is happening, people will learn to be more concise and stick to what they need to discuss to ensure everyone knows what they need to do, what everyone else is doing, and the general state of the Sprint.

How do you make sure timeboxes are been adhered to? I have learned through experience that it is unwise to throw projectiles at people if they seem to be going to deep in to the detail, as that can lead to minor injuries and unpleasant lawsuits. Tazers are generally frowned upon, as are most violent means. Ideally the team will police themselves at meetings, and call each other out if needed. They need to feel like they can do so, and may need help to get comfortable with it. But once they do, and the meetings are productive and complete within the timebox, then it should be a meeting that people want to attend rather than avoid.

The Treasure Island Retrospective

This short video demonstrates how to run a retrospective we devised and ran recently for one of our Scrum teams. It uses the  5 stages of a retrospective described by Esther Derby and Diana Larsen in their book Agile Retrospectives; “Setting the Stage”, “Gathering Data”, “Generating Insight”, “Deciding What to Do” and “Close Out”.

It asks the team to go in search of their treasure on Treasure Island, using their strengths to overcome any obstacles they might find on the way.  We hope you enjoy and thanks for reading/watching. If you use this we’d love to hear your experiences or any other opinions and thoughts you’d like to share with us about this retrospective.

Do you need a Scrum Master?


Recently Alistair Cockburn, one of the 17 original Agile Manifesto authors, posted a question he was asked by a person called Gaboo, about the role of the Scrum Master.

Part of any Agile process necessitates stopping and thinking about the quality of the product you are producing as well as the quality of the methodology that is being used (12th principle ~  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.) With this in mind, questions about whatever framework we may or may not use should not only be asked, but embraced and seriously thought about when brought up.

Gaboo wanted to know:

  1. Is there anything implicit which says that the Scrum Master must have background in software process improvement and psychology?
  2. If they don’t have a professional background, how can they judge team dynamics and software development issues?
  3. How can the progress of the team or the performance of the Scrum Master be measured?

I immediately saw why Alistair posted this question. These are all extremely valid questions as the role of the Scrum Master is a bit hard to understand in the business world. Managers are responsible for planning, delivering projects and organising the team. If a Scrum Master isn’t directly responsible for delivering the product and the team decides how they want to organize themselves, what is the Scrum Master responsible for and what kind of skills do they need?

I posted a response to Gaboo’s questions and I answered as best I could without using definitions and doctrine. I tried to focus on my experience with the Scrum Master role and how it fits into our team’s dynamic.

  •  Questions 1 & 2 were similar and I tried to tie them together with this response: 
    It doesn’t hurt to have experience in software if you are coaching software teams, but not in order to solve their problems. It may be useful to have similar experiences to that of the team so you can relate to them. The Scrum Master position is concerned with enhancing productivity through collaboration, not through software or a commanding influence.
  • Question 3, about measuring the progress of the team and Scrum Master, I answered with:
    I think the only way I can attempt to share any insight on this is to indirectly answer your question with the thought that Agile (Scrum) is a framework to encourage empirical thinking/reasoning in a team. If a team isn’t iteratively looking at what it’s producing and how it’s producing it, it isn’t progressing. Because of the iterative nature of Agile (and thus Scrum) this evaluation is always being made. Though there are many tools to measure progress and influence, the very act of iteratively analysing the team is a progress indicator unto itself.

To get the full context of my answers, and a few more tid-bits concerning the Scrum Master’s role with impediments, you can read my full response on Alistair’s blog post on Why do we need a Scrum Master?

These are my thoughts on the subject. I’d be interested to hear about anyone else’s experiences/reservations on the role of the Scrum Master.

The Rope Game

We’ve put together a short video segment on one of the many learning games we play with people to help demonstrate the power of Scrum and Agile.

The Rope Game from Boost New Media on Vimeo.

We’ve also included the instructions for the game below.

If you are interested in using games to help your Scrum teams, we discuss the topic on our latest episode of The Board, The Board – Episode 6


The rope game


3 to 7 minutes


  1. 6 to 10 people  –> to form the circle
  2. 1 person to stand out of the group
  3. 1 metre piece of rope, per person in the circle

How to play


  1. Ask one person to volunteer to be a “Project Manager” and step out of the team.
  2. Have the team form a circle (facing in).
  3. Give each team member a rope and ask them to hold it in their right hand and pass the other end to a person standing across from them.
  4. Ask each person, in turn, to pass their ropes across in the same manner until everyone is holding two ropes.
  5. Ask the Project Manager to direct the team so that it is untangled and standing side by side in a circle.
We normally allow them a minute to a minute and a half until we stop the exercise


  1. Get the team to form a circle again
  2. Ask them to repeat handing across the ropes to re-tangle themselves.
  3. This time, ask the Project Manager to simply observe and not say anything
  4. Ask the team to untangle itself (typically takes between 20 to 40 seconds)


This exercise demonstrates the power of a team’s ability to solve complex problems when they collaborate. It resonates with Scrum in that you encourage the team to be self organising to get the full benefit of their abilities.

If you try the game, please let us know how it went in the comments below!

Scrummaker: the customer validation process

On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.

A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.

As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.

Customer validation: the research process behind Scrummaker

Customer validation has been at the heart of this project. It’s actually seen us take a completely different direction to the one that, three short weeks ago, we thought we were moving in.

Originally, we’d considered building a tool to solve one of our own pain points: turning stories in Pivotal Tracker into physical objects for sprint planning and visible workspaces. At the moment, our Scrum Master or our Office Manager spend a not-insignificant amount of time each week pulling stories out of Pivotal Tracker as CSVs, dropping them into project templates in Pages, tidying them up, then printing and trimming. We’d identified this as a pain point and poor use of our time, and considered building a tool that would integrate with Pivotal Tracker and automate this as much as possible.

We used two frameworks to conduct and capture our customer research. One was Lean Launch Lab, a product that helps you store and visualise your customer research. The other was the Validation Canvas from Lean Startup Machine, a simple one-page format for displaying assumptions, hypotheses, and pivot points.

The validation canvas for our product research

Validation canvas for Scrummaker (from Lean Startup Machine)

We conducted research in a number of different ways. The most complex was using unbounce to set up a landing page for our theoretical new product. We used LinkedIn advertising to promote the page, and tracked conversions from people visiting the page to following a call to action to sign up or find out more. We ran a poll through the LinkedIn Scrum Practitioners group, and we also conducted a series of email and face to face interviews with Scrum practitioners in Wellington and around the world.

What our customer research rapidly showed was that our ‘printing out stories is a pain in the ass’ sentiment wasn’t widely shared. (Perhaps, being a design-led company, we worry a tad too much about everything looking good as well as working well.) Instead, what emerged was a cluster of concerns around retrospectives:

  • they aren’t always valued by teams and/or organisations
  • they are hard to run with distributed teams
  • it can be hard to generate actionable improvements
  • it can be even harder to track whether these actions are taken and what the outcomes are.

Some market research showed us that few tools already exist to tackle these problems. At this point, we felt confident that we had a good problem to solve. What could we build that would help Scrum teams run efficient and valuable retrospectives?

Our next step – and the next post in the series – was to run an experience mapping workshop to generate a product backlog …

Scrummaker, or, building a new Agile product in two days

On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool for teams running Agile retrospectives that we’ve named Scrummaker.

The purpose of the workshop was three-fold. We wanted to build a new product. We wanted to build a new product as a team. And we wanted to build a new product as a team using the Agile practices we’ve been working with now for about six years.

We’re now publishing a series of blog posts to record the two days of product development: what we made, and how we did in. The blog posts are only the beginning; we also had a crew of student filmmakers along for the two days, recording all the goings-on for a short documentary.

The first posts will cover the project lead-in: customer validation of our product ideas, the experience mapping workshop we ran to generate the user stories for the product backlog, the time-boxed technical discussion the team held to ensure we’d hit Thursday morning ready to work. There’s a post on the project kick-off, and then the meat of the series: what we learned from two days of compressed Scrum, and the product we came out of the end of the process with.

So grab a cup of whatever makes you happy and settle in for the read ….

  1. Customer validation for Scrummaker
  2. Experience mapping workshop
  3. Technical discussion
  4. Project kick-off

Business Analysts and Scrum projects: A short case study

In a recent post I discussed the question “Are user stories the same as use cases?”. This is a question that frequently arises in our Writing Great Agile User Stories workshop, and it’s often asked by business analysts. I’ve also been in Agile/Scrum training courses with BAs, who at a certain point in the day start worrying about where the BA role fits in a Scrum project.

The quick answer is: there is no Business Analyst role in Scrum – just like there isn’t a DBA role or a SysAdmin role or a designer role. You’re either the Scrum Master, the Product Owner, or part of the Scrum Team. There also isn’t a space carved out for a person to be responsible for requirements gathering and reporting.

The longer answer is that there’s still a lot of work in a Scrum project for a good BA to do. As Roman Pichler puts it:

what’s left to do for business analysts in Scrum? I have seen business analysts working as team members as well as taking on the product owner role successfully. In both cases, though, the individuals experienced a change in their daily work. Business analysts working as a team member often support their peers in product backlog grooming activities. As the business analysis activities are now carried out collaboratively, the business analysts often have time to take on other responsibilities, for instance, working with the testers or the technical writer. As a business analyst working on the team, you should hence expect to pick up new skills, broaden your expertise, and be open to work in new areas.

One small case-study

I recently worked on a short (6-sprint) Scrum project that had a nearly full-time BA allocated as a resource to the team. (Don’t you love that kind of phrasing? “allocated as a resource”. Savour it.)

We were creating a mobile interface for a cut-down set of the functionality available through our client’s current website. Our team was made up of a mix of our client’s staff and Boost staff: a Product Owner, the BA, two developers and a tester from our client; a Scrum Master, designer and me doing the wireframes from Boost.

Here’s what our BA did:

Working with the product owner

  • Research for writing user stories (usually by confirming how the current system works, and where there was and wasn’t flexibility to make changes)
  • Meeting with other parts of the business to explain what we were doing and what we needed, and to find out what they were doing and how that might affect what we were making.

Working with the team

  • Ferreting out system documentation
  • Getting screenshots of the system that I (working outside their network) couldn’t access, and reviewing wireframes with me
  • Helping write and QA’ing test cases
  • Getting wording signed off by other parts of the business (always harder than you think it’s going to be)
  • Getting approval from other parts of the business for use of a third-party plug-in.

Our BA attended all the planning meetings, retrospectives and stand-ups. Her work was managed just like the rest of the team’s: written as tasks and posted on the Scrum board. What she didn’t do was write requirements or use cases, or reports. There was huge value in having her on the team: she was our go-to person for all the tucked-away documentation and hard-to-find system descriptions.

Further reading

A four-part article based on a roundtable discussion amongst a group of Agile experts (including Alistair Cockburn, Roman Pichler and Ken Schwaber) on business analysis and Agile

Colart Miles has begun a promised series on the Clarus blog

Use cases vs user stories in Agile development

TL;DR – User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically (largely), removing the need to write use cases.

Are user stories the same as use cases?

When running our Writing Great Agile User Stories workshop, I’m frequently asked “So – are user stories the same as use cases?”. Often it’s a business analyst who asks the question; they’re accustomed to working with use cases, and are wondering where use cases fit in a Scrum project, and if they’re replaced by a user story.

Looking around the web, there’s consensus that use cases and user stories are not interchangeable:

My standard answer is that user stories are centred on the result and the benefit of the thing you’re describing, whereas use cases are more granular, and describe how your system will act. And then I say “Just bear me – it will all be clear in soon”. But I thought it was time to dig further down into this.

Use cases and user stories

Let’s start with some definitions.

A user story is a short description of something that your customer will do when they come to your website or use your application/software,  focused on the value or result they get from doing this thing. They are written from the point of view of a person using your website or application, and written in the language that your customers would use.

A user story is usually written using the format canonised by Mike Cohn: As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.

A use case is a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents, and generally include this kind of information:

  • use case title
  • rationale/description/goal
  • actor/user
  • preconditions (the things that must have already happened in the system)
  • standard path or main success scenario (what will usually happen, described as a series of steps)
  • alternate paths or extensions(variations on the above/edge cases)
  • post conditions (what the system will have done by the end of the steps).

At first blush, use cases look like a much better way of writing requirements than user stories. How will a team be able to implement something as wafty as: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos? Won’t it take some rigorous use cases to detail the requirements for the system? And that’s usually the point when someone in the workshop asks that question.

Writing use cases to flesh out user stories in Agile projects is certainly not unheard of (see here, and here). But it becomes clear as we move through the workshop that user stories are just the start of a process of understanding what the team is making that, by the end of its course, covers off everything a use case would have told you, but in an organic manner.

Acceptance criteria

User stories aren’t just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. For example, if this is your user story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:

  • A user cannot submit a form without completing all the mandatory fields.
  • Information from the form is stored in the registrations database.
  • Protection against spam is working.
  • Payment can be made via credit card.
  • An acknowledgment email is sent to the user after submitting the form.

Writing the acceptance criteria is the first step of fleshing out the details of your user story.

Sprint planning meetings

In the sprint planning meeting, the product owner presents the user stories from the top of their product backlog (ie. their highest priority features) and the team commits to the stories they will complete in the sprint.

As the product owner presents the stories, the team will ask questions to further clarify the user story and the acceptance criteria. Assumptions will quickly be confirmed or corrected, and any ambiguity about the requirements starts to disappear.

This assumption and ambiguity erasure continues as the team estimates the stories (if five people on the team rates a story as a 2, and one person rates it as a 5, there’s probably some questions that need answering). And it’s repeated again as the team writes the individual tasks for each story.


We’ve been fortunate in our Scrum projects, in that our product owners generally commit to attend the team stand-up. This is another chance for the team to ask questions, and also to make the product owner aware of restrictions, issues and opportunities are appearing as the story progresses.


I do the wireframing for some of our projects, and usually I start by talking to the product owner about the story, and sometimes making some paper or whiteboard sketches. I turn these into wireframes and then there’s normally a couple of quick iterations with the product owner as we ask each other questions, get feedback from other people, and hopefully squeeze in some user testing.

More recently, I’ve started reviewing the draft wireframes with the designers and developers working on the story. This helps flag up any questions they have, or restrictions I might not have been aware of. After the wireframes are approved by the product owner, I’ll brief the designers and developers again if needed.

Design and development

Although most of the details have been thrashed out during the wireframing more can crop up at this stage, and there are often more questions for the product owner about exactly how they want the backend of the system to behave. Pair programming is useful here, because two sets of eyes on a piece of functionality mean yet more questions and clarifications.

No user story is submitted for acceptance by the product owner until the acceptance criteria are satisfied and the definition of done is met.


This might sound like a lengthy process. In reality, it’s just what a Scrum team does all day. Rather than one person labouring over the use cases, the team works together to surface and satisfy all the requirements. The product owner can refine the original acceptance criteria in response to new information throughout a user story’s progress.

And finally, in conclusion

There are exceptions, of course – and there are times when the upfront research needed for use cases is important (I’ve got a blog post brewing on this). But my advice would be: don’t start writing use cases until your team specifically asks for them. And if your team does ask for them, spend some time in a retrospective digging into what they’re not getting from your current processes (for example – are the acceptance criteria unclear; is the product owner  unavailable; are you working with shitty documentation for another system). Then decide as a team how to fix the root problem.

Further reading

Advantages of user stories for requirements – Mike Cohn

Requirements 101: User stories vs use cases – Andrew Stellman

Want to know more about user stories? Check out our introductory series:

Could our FREE user stories webinar take your User Stories to the next level?

Join our experienced coaches in this FREE hands-on webinar and learn to write great agile user stories & craft an amazing product backlog.

Find out more