What the hell is a Sprint Review?

This is the last post before New Year’s Eve: so it is time to “review” the year which is going to give us the gift of enjoying the last days in its last month. That’s why I decided to spend few lines about Sprint Review.

2013 has been for this blog quite an interesting journey of 22 articles: I learned a lot by publishing them and I hope the 9000 readers (R)Evolutionary Agility had in the last 2 years have learned something as well. I wish you all an exciting and joyful 2014!

Some weeks ago I delivered a 3-days course for Scrum Masters. I usually visualize the agenda as a backlog of subjects we prioritize together throughout the training.

During a coffee break a guy approached me and asked: “I recognize the different ceremonies in the agenda, but I never heard about Sprint Review. We normally do a Sprint Demo: is it the same thing?”

“It depends on what you do in your Sprint Demo. Can you tell me more?”, I answered.

“Well, at the end of the iteration our Program Manager calls for a Demo meeting. All Scrum Masters are attending and reporting what we have been doing during the past 3 weeks”.

“So what are you demoing then?, I asked.

“We’re presenting a powerpoint slide set, showing a detailed report of the different activities during the Sprint, who was doing what and how much time was spent given the people allocation”.

Again? Yet another manipulated buzzword!?

And yet another empirical evidence of how an organization can produce so powerful antibodies to resist and protect itself from cultural change bacteria.

So let’s see if we manage to inject some virus of learning and growing mindset: these are usually quite effective in spreading willingness for improvement.

Let’s start from some why: why is a Sprint Review important? What is the purpose it is meant to serve?

Scrum is grounded in empirical process control theory and therefore uses an iterative and incremental approach to optimize the path towards a certain business goal by means of fast feedback loops. 

As any other implementation of empirical process control, it is based on 3 pillars:

1. Transparency

All information necessary to handle the process must be available to those handling the process

2. Inspection

The different aspects of the work must be inspected frequently enough so that unacceptable variances can be detected. Of course the skill and diligence of the people inspecting the work resul matter.

3. Adaptation

If the inspector determines from the inspection that one or more aspects of the process and the resulting product are unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation.

The Sprint Review meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint.

The Sprint Review is then an important learning point and a fundamental step in the empirical process control applied by Scrum. That’s why calling it just “demo” is mislabel, since this word does not capture the real intent of this ceremony. Let’s analyze what might be the learning points for the main actors:

• The Product Owner and key stake-holders learn what is going on with the product, what are the results of the Sprint and check whether those results are able to bring the whole Scrum Team closer to the Product Vision. The Sprint result will have anyway impact on the Product Backlog for the next Sprint Planning: new stories might be added, changed or removed and prioritization might change.

• The Development Team learns what is going on with the Product Owner and the market. They also learn whether the Sprint Result validated the assumptions they made during the Sprint Planning. For that reason it might be useful to review the estimates, to check whether they got confirmed after the story was actually built: in this way the team know how to estimate better and build a better baseline to relate further estimations. They’d better review also the different team metrics and the Sprint Burndown Chart to gather interesting data for the coming Sprint Retrospective. Review of Team Working Agreements and Definition of Done will indicate the team whether what they learned during the Sprint can affect the team’s rules or their quality criteria.

For these reasons, the most important element of the Review is the conversation and collaboration between the Team and Product Owner to learn the situation, to get advice, and so forth.

It is a public ceremony: the Product Owner, Team members, the ScrumMaster, plus customers, stakeholders, experts, managers and anyone else interested is allowed to attend and anyone present is free to ask questions and give input. The Scrum Master will work to maximize the learning of all participants.

Even though calling the Review just “demo” doesn’t really make the point, the demo is anyway an important part of it. But what does it make sense to demo?

Let’s have a look at some of the Principles in the Agile Manifesto:

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

3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

7) Working software is the primary measure of progress.

It doesn’t mention powerpoint slides, right? J

So the only demo which makes sense is showing an installation of an integrated potentially shippable product increment. BTW, the Product is the only language which everybody, from business to developers will understand the same way.

Remind: spend as little time as possible on preparing for the demo. If you need to spend a lot of time there must be something wrong somewhere.

If you read and liked this article, I have a question for you: 

How will you change your next Sprint Review?

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 – 3

Well in shape into 2013 after the end of the Great MayanCycle, let’s continue the posts thread talking about how to help a Product Owner team work effectively.

We talked already about how to setup the team and how we build the Product Backlog collaboratively.

Let’s touch today the way our team grooms and orders the backlog and I will start telling you the story of a failure.

A “good” failure indeed: one of those you learn something out!

Some months ago, facing the development of customer requests based on the business priority order, the team realized that implementing a new feature would have required moving to the new version of a 3^rd party we integrate in our system.

No big deal: they said!

And everything would have been ok, except for the fact that, after some weeks, we realized that the new version of this product was not actually properly working with our new operating system.

Result, as you can imagine, was: a lot of troubles, blaming games, fights, time wasted and, finally, the decision to roll back to the previous version.

What went wrong then?

The question is that requirements are prioritized according to business value, but Product Backlog is ordered instead, taking into account other factors than simply customer priority.

Otherwise, what would be the added value of a Product Owner?

My 10-years old son would be perfectly able to do tasks strictly following a prioritized list given by someone else.

Of course, I oversimplified the question a bit.

But not too much indeed!

However, out of this failure, we learned how to arrange our backlog better, putting into it competence and brains, not only from Product Owners, but from developers and managers as well.

Now, before ordering our backlog, we take into account 3 parameters mainly:

1. Business value
2. Dependencies
3. Risks

So, before giving the backlog a certain order, we evaluate the business value ranking coming from Product Manager, we consider the Product Anatomy and rate both the technical and non-technical risks we see associated to the requested MMFs. 

So the PO team defines the backlog order, putting high in the list not necessarily the most valuable items, but obviously the ones which the others are dependant from. We give special attention to the riskiest features, many times splitting them and touching them first, so that we can have an early feedback and take actions accordingly.

Actually there’s a fourth parameter which comes into play many times, that is cost: since the goal of a Product Owner is maximizing the Return on Investment, one could choose to anticipate cheaper features, given a certain business value.

That’s the kind of brain we have to put in, to move from prioritized requirements to an ordered backlog.

What else would you suggest to consider in order to get a proper backlog ordering? 

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!