Agile negotiation

What do you see in the Product Owner role? There are many aspects to the Product Owner role. Let's talk about how the work comes to the team. Many Scrum teams see their Product Owner responsible for refinement, although the Scrum Guide explicitly puts refinement into the responsibility of the team. That doesn't mean the PO can't play a valuable role in refinement. Let's talk about negotiation.

Why the Product Owner needs to negotiate

If your team is using "INVEST" as part of your Definition of Ready, backlog items should be negotiable - but why should they be negotiable if you don't want to negotiate?

In a recent post, I discussed what "user stories" actually mean, so I'll skip on full repetition.

When you work with stories, then you're talking about someone who has a problem and an interest in having a solution. On purpose, we refrain from equating problem and solution for a while - because if people knew the best solution for their problem, they probably wouldn't have it anymore.

Negotiate interests

At this point, the different interests of the different stakeholders enter the stage: 

Why is the user interested in getting this problem solved quickly? Why would developers be interested in helping? What are our financial interests? Our strategic interests? What are everyone's primary interests? How far do they overlap? What can we do to align them and reduce conflict?

Different approaches can later be weighted against each other using aligned interests as objective criteria when making decisions.

Negotiate the approach

There is always more than one way to deal with a problem. Common strategies are:

1. Accept (do nothing)
2. Avoid (create a work-around)
3. Ameliorate (reduce the impact)
4. Cover (make it invisible to the user)
5. Resolve (eliminate it once for all)

Descending from 1-5:

• User pain decreases
• User effort decreases
• Delay increases
• Engineering complexity increases
• Engineering effort increases

The "null hypothesis" is always that we accept the problem, i.e., don't do anything. The Product Owner can direct the approach by elaborating on optimization goals, such as: "The user can't bear with it and we need to act fast" - or "We don't have much of a budget for this, but need to make it easier for the user".

Negotiate a compromize

You will make a trade-off. Questions such as "How much pain does the user have?" can open up discussions about compromizes, such as: "If this problem only occurs once a month, we'll fix this manully next time - to have enough time for our [other important thing], then afterwards, we'll resolve it".

Any chosen path will incur costs to at least one of the factors above. The Product Owner should defer a decision until there is enough information to weigh off plausible alternatives and put these into proportion with as much objectivity as possible, 

Negotiate the solution

After aligning interests and deciding on a strategy, different scenarios can be explored. These scenarios may result in solutions that are more or less compatible with our interests. They can be weighted against each other based on such objective criteria. While tools like a Pugh Matrix tend to be overkill, the team needs to come to an agreement that is "the preferred way of solving the problem" based on the optimization goals. 

The final strategy may be a compromize of multiple approaches, such as "We'll do a quick fix now, then spend a larger amount of time later to resolve it". 

The PO, central negotiator

The Product Owner can have more than one negotiator role: 

They might negotiate business interests with customers and/or developers - they might take the role of the customer and negotiate customer interests with developers - or they might facilitate the negotiation between these (and other) parties. 

tl;dr:

Product ( / Story) negotiation relies on four key rules:

1. Separate people and problems
2. Focus on shared interests 
3. Create options
4. Use objective criteria

Apply these four negotiation rules to discover highly satisfactory solutions.

The Product Owner is responsible that negotiation can happen - the team is responsible for making it happen. 

Negotiation opens up solutions, rather than discovering ways of shoving someone's opinion down others' throats. Negotiation is the first step towards co-creation and mutual satisfaction.

Start negotiating stories today!

Choosing an adequate sprint length

New Scrum teams must answer the question: "What sprint length should we choose?" Being inexperienced in Scrum, beginners often address that question to me. I have an opinion - which does not matter in itself. Let me give you the reasons why I have formed my opinion:



I advise new teams to start with 1 week sprints, because:

1. You from new habits quicker when you have the ceremonies every week.
2. You learn to deliver smaller batches when you MUST get some thing done within a week.
3. The ceremonies are shorter and feel less invasive.
4. You'll do more experimentation with the process.
5. You get faster learning cycles.

There is another reason that may be more compelling, depending on the reasons for choosing Scrum in the first place: Team effectiveness.

Retrospectives are the Scrum ceremony where process changes are discussed. I call them "experiments", because the team is changing something they hope will work out - not something they have experience with.

If you do 1 significant process experiment per Sprint, denoting that Significant means a 5% difference in results (although this is hard to quantify), assuming half of your experiments succeed, within 1 year:

• If you do 1 Retrospective every 4 weeks, you will be about 35% better. That will hardly be visible.
• If you do weekly Retros, it will be about 200% better. That is a massive leap which everyone inside and around the team will notice.

Where do you want to be after your first year?

Guide: Sprint Planning with the Task Design Board

When attending planning sessions, I often realize that teams are stumped about the idea, "What is a meaningful task?" They come up with the standard tasks, "It needs to be developed, tested, deployed" - well, that's true. Yet, it's not very value adding. And it makes the planning meeting quite boring.
Here is a suggestion how you could approach task extraction in a way that adds a significant amount of value - and fun.

An example Task Design Board

The task design board

Let's check out what a "task design board" is: Instead of hudding around a meeting table and looking at a projector, developers make their work visual. They draw a design model representing their area of work - in our case, the architecture. Then, they add task cards in places where they intend to do work, denoting what they want to change. 

Step 1: Create a model

As we discussed above, in our case, we created an architecture model. Depending on what your backlog items are, you may also look into causal-loop diagrams, entity-relationship models, flowcharts or whatever floats your boat (pun intended). The model doesn't matter - as long as everyone understands why the model is useful and agrees that the model adequately displays the problem which the team is working on.

It's important that people understand the difference between "what is" and "what will be", because that is where the work-to-do comes in. In some cases, "what we still need to explore" is also a valid option. A suggestion may be to use different colored pens or small icons to denote these differences. 

Step 2: Defining tasks

After we know where we need to do some work, we add tasks which define what work we intend to do in order to move "from here to there", i.e. to the desired future state that solves the problem at hand. In the first draft, tasks can be very crude, such as "Website" - which is enough to indicate that there's work to be done.

Step 3: Refine tasks

This step is completely optional in a cross-functional team with close collaboration. If the team consists of specialists with limited interaction points, some tasks may need to be refined in order to be "workable". Let's take our example "Website". Maybe we need to break that down into "Set up webserver", "Create HTML", "Create CSS". The key in task refinement is not to have microslices of work as much as creating task slices that can be delivered without causing handovers delays in the process. The level at which you slice is defined by the team's skill distribution.

Step 4: Slice tasks

This is yet another optional task, depending on how quickly the team delivers. To decrease the risk and impact of blockages, tasks should not take more than 1-2 days. If the team has discovered that some task cards they created are probably significantly larger than 2 days, it may be a good idea to slice them down even further using techniques such as FURPS+, Impact Mapping or Specification by Example.

Step 5: Reduce tasks

You've probably run wild creating 100 tasks for a single Sprint now. Congratulations! That was fun. Now, we need to get pragmatic: Which of these tasks are really needed - and how many of them can we even do in a Sprint? Keep value and simplicity in mind. Your most important tool in this step is the trashbin, where all tasks go that have been created in a design frenzy. 

Step 6 - Order tasks

After you know what you really want to do, put tasks into a sensible order. A few constraints in ordering will go a long way.

1 - Cluster around value: Put tasks together that result in deliverable, visible customer value.

2 - Arrange by value: Start with the clusters that deliver the highest customer value.

3 - Arrange by feasibility: Inside the cluster, first do the tasks that could be done right now, i.e. that don't have unmet prerequisites.

Step 7: Assign tasks

This step is highly arguable. I personally don't recommend doing this in Planning already - yet some teams find value in this. Take a look at the task cards and ask around who will do what. 

Task assignment needs a few rules to work out properly:

1 - Pull: People take tasks. Nobody is allowed to "give" a task to anyone. 

2 - Consider Capacity: Nobody should take more tasks than they are confident they can handle.

3 - Think team: Look for ways to collaborate and do tasks together in order to proceed faster.

Step 8: Confidence vote

To conclude, let everyone take a step back and take a look at the created Sprint Plan. 

Does anyone see some unfeasible tasks? Is someone overburdened? Have we missed something? 

Everyone raise their hands in a display of confidence: Can we do this?

5 fingers = Yes!!!

3 finger = I have some concerns.

0 fingers = No way.

Numbers inbetween are ok.

If we get less than 4 fingers from most team members, we should discuss and resolve the problem.

Summary

Are you fed up with boring projector shows and ineffective planning sessions?

Try the Task Design Board as a simple, effective and energetic tool to run a Sprint Planning on low-tech, tipping deeply into the brains of developers to come up with a feasible, exciting plan.