The User Story Workshop

User Stories in Oxford by Jacopo Romei / CC BY 2.0

What can you do when you need to write a considerable number of User Stories in a very short timeframe?

Why a User Story workshop? 

It is a useful tool to achieve the goal of writing many stories fast, especially when the development team has a lot of technical knowledge, or there is a lot of knowledge outside the team to be used to complement Product Owner’s domain knowledge.

What is a User Story workshop? 

When starting a new Release, I suggest to run a a workshop with the Product Owner, the Development Team(s) which will build the specific product and all people who can contribute, regardless of their role. 
The goal of the workshop is to come out with as many User Stories as possible, which can solve the problem(s) represented by a given number of requirements.

How to run a User Story workshop? 

Here is the structure I usually propose:

1. The Product Owner presents the goal for the next Release and the most important requirements. This normally takes about 1 hour: participants normally ask clarification questions

2. Participants are split in groups of 4-5 people and we do a number of (usually 3) 1-hour iterations structured like that:

2a. Group brainstorming to elicit as many stories as possible (30 min)

2b. Group work integration, where groups review each other work, find similarities, remove some stories, etc. (30 min)

The next iteration might continue on the same requirement or on a different requirement. Sometimes I tried other creativity techniques besides simple brainstorming, like Lateral Thinking techniques, e.g. the anti-solution.

Especially if it is a newly formed team, not so used with writing stories, I provide a pattern to follow to brainstorm stories.
 I ask the team to look at the system from outside-in and ask themselves who, what and why:

- Who is the user who will benefit from the specific function?

- What is the function which might contribute to solve a certain problem?

- Why is that function needed (to solve which problem)?

My experience

Generally speaking I found the User Story workshop very effective: it helps the team focus on the goal and make an efficient use of all brains around. You can easily write 50 User Stories of different granularity in 4 hours: sometimes more time is needed to achieve the intended goal, but I always prefer to start with no more than 4 hours and have other sessions if needed.

Learning

In order to make the US workshop effective, the people involved should have been trained in what a User Story is and how to split the work in small slices which cut the system vertically and allows building an iteratively evolving product which continuously stays shippable. 
When needed, I propose and facilitate a very effective workshop to teach how and why splitting a product in small vertical slices: the Elephant Carpaccio exercise invented by Alistair Cockburn.  
I do recommend these 2 hours of learning, engagement and fun.

What is preventing you to try it out tomorrow? 

Product Backlog Gardening, with love!

Wikipedia (btw, the most successful example of an emergent product from a self-organizing team) provides the following definition:

Gardening is the practice of growing and cultivating plants. It involves an active participation and tends to be labor intensive, which differentiates it from farming or forestry.

I cannot find a better metaphor to describe the continuous work that a proficient Product Owner needs to do with the Product backlog.

1. First step is actually to plant a seed. That’s the purpose of defining the Product Vision together with the customer, answering the questions: What do we want to accomplish? And why? All gardeners know that quality of the seed is essential and of course you need to plant cherries if you want to get cherries and you cannot get roses if you plant onions.
2. After you plant the seed, you need to water and fertilize it. Then the first small sprout will come out of eliciting a set of SMART (Simple, Measurable, Achievable, Relevant, Traceable) requirements, focusing on customer needs, on the problems to solve or better on the problems worth solving.
3. The tender small plant now needs a good environment to strengthen and grow. Gather all needed people in a User Story workshop and collaboratively write down as much as stories as possible. You as a Product Owner, exactly like a good gardener, do not have to do all the work yourself: you need proper tools and a fertile land. So use the best land, i.e. the power of the diverse brains around you. Present your Goal for the next Release Cycle and the related Requirements. Make use of creativity techniques to elicit as many User Stories from the Team as possible. Try to identify top MMFs and break them down into User Stories, or cluster User Stories into MMFs.
4. Good User Stories should be INVEST
• Independent: Stories are easiest to work with if they are independent.
• Negotiable... and Negotiated: A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by Product Owner, programmers and testers during development.
• Valuable: A story needs to be valuable to the customer. Think of your Product as a multi-layer cake: a story is supposed to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it "right"); but a full database layer (for example) has little value to the customer if there's no User Interface.
• Estimable: A good story can be estimated. We don't need an exact estimate, but just enough to help the customer rank and schedule the story's implementation. Being estimable is partly a function of being negotiated, as it's hard to estimate a story we don't understand. It is also a function of size: bigger stories are harder to estimate. Finally, it's a function of the team: what's easy to estimate will vary depending on the team's experience.
• Small: Good stories tend to be small, such that the team can do 6-10 stories in a Sprint as thumb rule. Above this size, it will be too hard to know what's in the story's scope, it will delay the feedback loop and increase the project risk.
• Testable: A good story is testable. Writing a story carries an implicit promise: "I understand what I want well enough that I could write a test for it." Teams are made more productive, by writing customer tests, in terms of Acceptance Criteria, before implementing a story.

INVEST is not only an acronym, but means the Product Owner needs to invest time, energy, skills and, why not , love, to make the plant flourish like all passionate gardeners do. And you cannot achieve it on your own: you can have a say on the "INV" part, but you will never get the "EST" without your team. Remember: Gardening involves an active participation and tends to be labor intensive, which differentiates it from farming or forestry.

5. A good Product Backlog is of manageable size, more granular on the top and more general towards the bottom, so that you do just enough, just in time work. Continuously trim useless leaves to give more space and lymph to the buds going to bear fruit soon: the User Stories being developed in the coming iteration and transformed in a potentially shippable product increment. Nevertheless continue watering and fertilizing the plant, looking a bit ahead to set the stage for later buds and fruits.
6. If you want to collect many fruits after each Sprint and thus maximize the Return on Investment, you might need to split User Stories in smaller chunks. But beware: splitting by architecture or by implementation details is a common mistake. It creates smaller stories, but fails several of the other INVEST criteria and then does not bear fruit. There is no too small story, unless it fails delivering value to customer. You can find a suggestion of possible good patterns to follow when splitting stories and still keep them INVEST here. An awesome and useful mindmap guiding you through the different patterns can be found here.

GIGO theory

One of the biggest causes of poor Product quality is a poor Product backlog, exactly like a sick plant cannot bear juicy fruits: GIGO theory applies J

So are you constantly gardening your Product Backlog with love?

Or are you expecting to harvest without hard work and passion?

I’m sorry to say that you will only collect invaluable fruits, my friend!

The importance of working with requirements

Two weeks ago (and the week before) I held a couple of sessions of Product Owner training in Sweden. 

As you know, I’m particularly interested in Product Ownership, being such a critical (and often underestimated) activity for the success of an Agile organization.

Anyway, regardless of this, every time I facilitate a PO training, one of the most interesting discussions happens around the subject of requirements. And the reason is that even experienced analysts or system engineers are sometimes not used to work with requirements properly.

The first important concept, which looks straightforward and totally sensible, but happens to be pretty hard to apply, is that a requirement is expression of a need, not a specification to implement.

It is an item in the space of problems: it is a problem to solve, not a function to deliver. 

On the other hand developing SW is just about solving problems, not writing code, right?

For instance, if one says: I want a bridge, is this a requirement? Is it a problem to solve or a solution?

A right conversation would then be: 

- What is the need behind this request?

- I want to cross a river without getting wet.

Eureka! This is a requirement and, as you might guess, this opens up more than one option to find a proper solution. One solution is definitely the bridge, other solutions could be a boat or a raft or even swimming. And you don’t even need to build anything in the latter case.

This is a very important job: understanding the real need behind a customer request. That’s why we don’t say writing requirements or defining requirements, but eliciting requirements, because it is about digging out real problems and helping the customer understanding her real need (or at least making a hypothesis on the real need, which must be validated through a fast feedback loop).

Then you as PO use your brain, your skills, your domain knowledge and the brains in your team to translate the need in business solutions, you can write in forms of User Stories, which is the language you speak with your team.

Requirements are instead the language the Product Owner speaks with customers, but it would be too easy and not profitable downloading the requests on the team as they are. Challenging customer needs is a very crucial activity for a Product Owner to be able to find a solution compatible with business and maximize the Return on Investment. 

I repeat many times to my PO team: your job is not to push your team to do as much as possible – your job is to challenge requirements, so that your team can do as little as possible.

Cutting some scope because it is not needed has an effect that no efficiency program whatsoever can ever beat: effectiveness eats efficiency at breakfast every morning.

Unfortunately I saw too many times the pattern of jumping directly into solution mode as soon as a request arrives and business solutions masked as requirements.

Buddhist masters know that, if you spend enough time in finding and formulating the proper question, the question itself will contain the answer. But how do you feel is the ratio between the time spent on defining the problem and the time spent on the solution in your context?

How to build a big product in a collaborative way – 2

In the last post we said that the PO Team’s job is to collaboratively develop a unique Product Backlog to feed all development teams.

So: how do we do that?

Look at this picture.

We basically do it iteratively, so that at each step we do the cheapest possible amount of work to verify our assumptions, get fast feedback and take a business decision together with our stakeholders: whether continue more or less on the assumed path or rather pivot (or even drop the development).

Given a customer request or a business opportunity, we start writing a Vision of what we’re going to develop (a pitch to explain what we’re going to do and why) and eliciting requirements in terms of needs and problems to solve.

We do it together with all involved stakeholders to be sure everyone is aligned. The requirements are then prioritized and basically divided in 4 categories: must have, should have, nice to have and must not have.

So far we stay on purpose in the problem domain and not consider the solution yet: in order to find the right answer, it’s better to spend time finding the right question.

And whether the question is worth being answered indeed.

The next step is to make a quick architectural analysis and try to identify a possible structure of MMFs (Minimum Marketable Features), which makes sense for the highest priority requirements. This requires again a collaborative approach with stakeholders and, if the team does not have all the needed domain competence, a PO pairs up with a system architect to get some help in the high level solution sketch which will inform the coming backlog preparation.

At this stage, a first cost estimation is provided: a relative cost estimation in story points, having actual efforts of already developed features as baseline.

MMFs, for which business opportunity is still considered valid at this point in time, become part of our global Product Backlog and represent items which can be pulled by any PO in the team to be worked upon and produce more detailed items in a hierarchy from epics to really INVEST User Stories. Pairing within the PO team and involvement of development teams, as well as collaboration with people from QA and Customer Support, help build high quality backlog items as a necessary condition to be able to build a high quality product.

The cost estimation is refined iteratively, leveraging on estimation from development teams actually doing the work.

A release plan is also provided, either as scope first planning, leading to provide a possible lead time interval, or a date first planning, leading to a scope scenario interval. The release plan is updated at the end of each Sprint taking into account historical data on team velocity and possible re-estimate, give the newly built knowledge in the iteration.

Daily work on the different global backlog items is followed up during a 15-min standup and work planning for the coming day is collaboratively agreed, considering which are the most important tasks to be accomplished to come closer to the project goal.

Next time we will have a look at how we groom and we order the global Product Backlog, so that the whole organization, including the PO team, is focusing at any point in time on the most important items.

How to build a big product in a collaborative way - 1

What happens when you have a product too big to be built by one team within the timeframe needed by your business?

You might answer: Well, I allocate more teams and then create an organization structure where each team is accountable for their part and with a project staff, headed by an expert project manager, to coordinate everything.

I do not want to judge this answer. However let’s have a look at the Agile principles:

• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
• The best architectures, requirements, and designs emerge from self-organizing teams.

What do I get out of this??

Well, first that SW development is a collaborative game by its nature: there’s no complex problem which can be solved by one person in a time which is compatible with modern business needs.

Secondly that self-organization and servant leadership are some how embedded in being Agile.

Furthermore, if you look at Scrum, you will find only 3 roles: Scrum Master, Product Owner and Development Team.

I'm sorry: no project manager whatsoever.

Beware! I’m not talking about people here: there are plenty of great project managers serving with passion and competence their organization. 

I’m rather referring to roles and their effectiveness in an Agile context, in terms of: What is the probability I might have success in an evolving reality?

Said that, what I would suggest to a Scrum organization is to setup a Product Owner Team.

Yes: a self-organized team formed by all development teams’ Product Owners collaboratively working together. And I’m suggesting that, because I’m currently coaching a PO Team and I would like to tell my experience through this and some other post I’m planning to write.

Of course a team does not make sense if they do not have a product to build: the PO Team’s job is to develop a unique Product Backlog to feed all development teams, so that the following is ensured:

1. the whole organization is focusing at any point in time on the most important items
2. the development teams are as much independent as possible so they can move fast with little need to coordinate each other
3. the overall architecture of the system is preserved 

Like any other Scrum team, a PO Team might better have a Scrum Master or Team coach (it’s just me in our case) and a Product Owner, who is in charge to give a final word on the overall priority in case of conflicts.

To tell you our story I will start from the beginning and that’s the team setup.

In a recent post I described how it is important for a team’s success to set the stage to high performance and that’s just the same crucial if we’re talking about a group of normally quite senior people who need to learn how to collaborate for serving the entire organization at best, instead of only cultivating the silos they felt responsible for.

And we really started from the foundation by writing together our team vision and the ground values we wanted to build our team upon, as you see in the pictures below. After few months I really recognize that this exercise had proved to be tremendously effective.

So we set the first draft of our working agreements.

Since I wanted to introduce the Scrum values in the team in an organic way, I let them decide completely how to organize in the first place and here come our ceremonies:

• Global Backlog grooming once a week
• Global Release planning once a week
• 15-min daily standup everyday
• Review of work done at least by another team member according to our Definition of Ready
• Team retrospective once a month

I will describe each of these ceremonies, make you see our awesome task board and tell you how we build our backlog starting from customer needs in a number of coming posts.

Talk to you soon!