How to make great Sprint Review

Scrum Reviews have been for a long time left out of our focus. Teams and ScrumMasters are asking how to improve Sprint planning, Standups, Retrospectives, but most of the time there are no real questions related to the Sprint Review. So how to make the Sprint Review great? Firstly let’s review the goal of this meeting which is to get feedback on our product. So no status of done vs. not done Product Backlog Items has any space here. No slides with any Burn-down or Burn-up charts, no velocity comparism.

The Sprint Review shall show real working product to our customers so they can give us a feedback. Yes, to the customers, not Product Owner (note that customers are all stakeholders, users, people who pay for the product, simply anyone both internal and external who has any expectations from that product). Showing the product to Product Owner makes no sense as he is part of the Scrum team and collaborated on the solution during the Sprint.

We don’t present technical solution, but business value delivered and we let team members take the opportunity to show that they did and get the applause :). However, if in some rare cases you happen not to get that enthusiastic feedback, and your customers get angry for any reason, the Product Owner makes himself visible and protects the team. After all it’s his responsibility to understand the customer well enough so those misunderstandings won’t happen.

Your Sprint review is great if you …

  • Show the real product
  • Let users experience it
  • Don’t have any presentation / slides / status
  • Development team is presenting
  • Invite real customers / users
  • Product Owner is most of the time quiet and doesn’t need to interfere

User Story as a Card

User Story is one of the most common formats how to write Product Backlog Item. It has specific format which forces people to focus on business value.

As a [user | role| persona]
I want to get [functionality]
So that I get [business value]

As an example of such User Story for my online beer store called “Berrer” we can write the following:

As Jon (busy manager with no time)
I want to get beers selected by “Beerer”
So that I can impress my friends by variety of rare brands.

It shall give us three different information – Who, What, and Why – which must fit together and once you read it to someone it shall create consistent story together. As you may have noticed the User Story looks at the functionality from the business perspective and is customer centric (note that customers are all user, stakeholders, other teams, … ). We never define how exactly it shall be solved, but describe the business impact we want to achieve.

Write Acceptance criteria was never good idea

Having that definition, companies are often missing the place where to write the exact specification. But there is none. It’s all about conversation. It should fit a small index card. Having said that, teams are still fighting and try to keep it as close as possible to the traditional detailed specification. One way how keep it close is to add detail as Acceptance criteria. It usually looks as checklist of all possible details you shall/shall not implement. It seems to be useful for teams who have limited understanding of business and product but it’s not. To give you an example of such Acceptance Criteria for the above defined User Story, it can look like this:

  • Beers from all continents
  • At least one beer from Belgium
  • Several small local breweries
  • One light, dark, Ale, Pils

As a result of it development team is not involved in the story definition anymore. They just take those points one by one and implement it. If it’s not working as we missed something, it’s not their fault but the Product Owners’. He shall have made the missing piece part of the Acceptance criteria. So let’s have a look to better solution.

Define Conditions of Satisfaction instead

As we said before, User Story is about conversation. It shall be simple, clear, and easy to remember. If you write well so it is small enough, there is no need for any additional information at the back side of the card. However sometimes you might find it useful to stress certain expected behavior / impact. In such case we turn the User Story card and write the Conditions of satisfaction. For the above defined story it might be:

Jon can impress his friends by selection of all different tastes of beer selected from micro-breweries across the world.

As a result of this the team is focusing on solving user problem instead of implementing what was defined before. The implementation usually starts with conversation. How can we deliver the more value with less effort? What is the minimal functionality we have to deliver? How can we address his needs? We need everyone involved, everyone interested, and everyone understand the overall business, personas, their needs and their dreams.

It may take bit longer at the beginning, but it’s worth investing the effort as the committed team which is living by the product can always come up with better solution then one Product Owner.

Writing Acceptance criteria is our legacy from traditional world, while defining Conditions of satisfaction is very Agile. Agile and Scrum is mindset. If you have it, it doesn’t matter how you write your User Stories because you already understand the fundamental difference. It’s about value to be delivered to the customer, instead effort, items delivery, and velocity. If you don’t, changing only the label won’t help. You would have to significantly change the way you think about Backlog items and that might be very painful and long process where User Story format with Conditions of satisfaction will help. I went through that change with several companies during Agile Coaching and it was always worth of the effort. If you want to get bit more practice, I also teach it at CSPO – Certified Scrum Product Owner class.

Product Backlog Example

When I teach Agile and Scrum classes, people often ask for Product Backlog Example. In order to start, you don’t need any complex tool. You can start with paper index cards and if you like simple Microsoft Excel or Google Sheet.

The minimum Product Backlog you need can be as simple as the card for each functionality (one column in the Excel):

Automatic beer selection for the party
Choose new beer to taste
Order favorite beers again
Recommend expensive beers

As I wrote in the previous blog about User Stories, the most common way how to define Backlog item is User Story. In that case you might want to add name for fast reference (however when you are using index cards you usually don’t do that and visualize by underline or color some important part), and if needed add conditions of satisfaction to the back side of the card.

Name
UserStory
Conditions of Satisfaction

Automatic selection
As Jon (busy manager with no time), I want to get beers selected by “Beerer”, so that I can impress my friends by variety of rare brands.
Jon can impress his friends by selection of all different tastes of beer selected from micro-breweries across the world.

New beers to taste
As Jon I want to see beer catalog so I can choose the some new one to taste.
Jon can see different tastes directly from the catalog page and don’t have to go into beer details.

Favorite beer order
As returning customer I want to see my favorite beers, so I can order them again.
(keep empty – conditions of satisfaction are optional).

Recommend expensive beers
As Store Owner I want “Berrer” recommend expensive beers so we increase our profit.
Customers are not feeling under the pressure to spend too much.

If you like you may also add a few optional fields like ID, Estimate, Epic, and Priority(which can be used to sort your Backlog in Business priority order). They all fit the index card space, but if you like to use any tool, it may look like this:

ID PBI Estimate Epic Priority
234 Automatic beer selection for the party 20 Order 1
556 Choose new beer to taste 8 Order 15
123 Order favorite beers again 3 Order 40
89 Recommend expensive beers 5 Profit 50

That’s it. As you see you don’t need any complex tools to handle your Product Backlog. Paper index card or Excel sheet is more than enough to take care of “deep enough” Product Backlog and to define clear Product Backlog Items. So don’t make it more difficult than it is.

Only estimate when it makes sense

Many Scrum teams are asking at the classes how shall we estimate Backlog Items / User Stories? They seem not to be happy with my reply that you don’t need to estimate at all in Scrum. I try to explain. Estimates can be useful. But in that case something has to happen as a result of the estimation process. I give you few examples of such good situation:

  • Based on the estimate Product Owner decides on priorities. From the two same value stories we prioritize the smaller first as that value is cheaper.
  • Based on big effort estimation we talk about how we can split the Story so we increase the ratio (value/effort).
  • Based on the estimation Product Owner decides not to invest into that Story and remove it from the Product Backlog.
  • We had a good discussion during the estimation process which results in common understanding of the functionality (sometimes all team members feel they understand it, but once we start estimation – for example Planning Poker – we find out that we all have a different functionality in mind).
  • Learn some useful insights from other team members about it. I.e. that testing is going to be very difficult, security is a huge risky issue here, etc.

If nothing from above is applicable, and you only use it to fill estimation box in your tool, you may stop wasting your time.

Finally to estimate when the release will to be done you can better use number of stories done per Sprint than any estimates = guess.

Product Owner is an investor

Product Owner role is usually more understandable for companies that the ScrumMaster role. After all, companies have someone responsible for the product or business. So that’s the candidate. The problem starts when we deep dive into the role understanding and find out that Product owner shall not only understand the business but needs an authority to say “NO”. If you don’t, we mostly end up being late, with stress and low product quality.

How the Product Owner shall decide on priorities and how shall they know when to say “NO”? Overall it’s simple. Apply simplicity rule. It’s already in the Agile Manifesto as one of the principles. ‘We maximize the work not done.’ It has its roots in the research saying that 60% of a successfully delivered product is never or rarely used. So why do we keep investing into those features. Isn’t it waste? It is. But it’s hard to say no, so Product Owners keep prioritizing those features. Instead they shall act as investors and evaluate if the expected benefit will be paid off. If yes, do that. If not, let’s start a conversation or a negotiation with the customers about what else can we do to help them with what they need. The functionality they asked for are just one option how to achieve it.

Who is the great Product Owner?

  • The great Product Owner is an investor – imagine you would invest your own money into functionality you prioritize for the next Sprint.
  • The great Product Owner must have an authority to say NO.
  • The great Product Owner must be good at communication, always search for another option how to deliver maximum value to the customers with least possible effort.
  • The great Product Owner shall understand that your customers (internal stakeholders, users, … ) have wishes. Those wishes often contradict with each other so you can’t make them all even if you have unlimited resources. It’s up to you to decide where the highest value is, and skip the rest.
  • The great Product Owner must have business knowledge about the product and understand the customers – it’s not a technical role.
  • The great Product Owner shall have a time to spend with the team to build good relationship with them, and to make sure your team understands the purpose of the product/release/Sprint.

If you don’t have all those, don’t worry. But eventually that’s who you shall become as a Product Owner.

Agile Prague Conference

Agile Prague Conference, which I organize in Prague every year, has already been  here for 6 years. We are sold-out again (the only way how to get to Agile Prague 2016 is to attend LeSS workshop). This time we were already sold-out one month before the event, which is going to be 12-13 Sep 2016 this year. But don’t worry. We don’t want to make it bigger next year. Our mission is to offer the best of the best speakers with hands on experience on Agile, Scrum, Kanban, XP practices, but also share experiences from leaders of Agile organizations with their transformation, Scaling, etc.  We don’t want to grow, as the biggest part of the conference learning is hidden in conversation you can have with other participants and our creative thinkers – the speakers. In order to make it possible, we can’t be too big. I’m attending several huge events every year (Agile 20xx with over 2500 participants and Global Scrum Gatherings with over 1200) and compare the learning and experience I got there with small local events I’ve been speaking at (Big Apple Scrum Day (NYC), Scan-Agile, AgileSlovenia, ACE, … ). I like the smaller events better. It’s compact, easier to approach speakers, easier to reach into people again and build on top of the conversation we started before we all run to another session.

Every year we try to attract the best international speakers and bring their ideas and experiences to the Czech Republic. We are small country so it is very unique opportunity for our local Agile community to look at Agile in wider context. As the program is high quality and our conference is getting great references from past year audience and speakers, we attract more and more participants from Europe and other countries.

So if you’ve never been to Prague you can already mark the next year date into your calendars – it’s going to be Sep 11-12, 2017. We do our best to attract wonderful speakers for you again. If you are a speaker and you or your family never got a time to go for holiday to Prague, submit your talk next year and we give you awesome opportunity to combine conference and sightseeing all together. We offer a private guide to our speakers and their families (so they have a program with us while you are at the conference). You will not only have an opportunity to speak at one of the best Central European events but also can enjoy history, and local atmosphere with us.

Looking forward to see you this year at Agile Prague Conference, and hope to see you next year again.

What Scrum has and Kanban is missing

In my last post I made a point that Scrum contains Kanban. So let’s look at it from another angle. Let’s see what is the most important aspect Scrum provides and which is missing in Kanban. It’s not about specific roles or meetings. It’s not even about iterations. It’s the purpose driven aspect. In Scrum, we build a Product Backlog, which shall be ordered by business value. It is not meant to be any todo requirement list. It’s a tool which allows us to split the tiny most important vertical slice of functionality, deliver it and get fast feedback from customers.

Product Backlog needs very strong foundation, otherwise the prioritization gets hard or even impossible and you are back at reactive mode we tried to avoid. In Scrum, we want to form a strong clear product vision, and then talk about what we shall deliver next Sprint and form it as a Sprint vision called ‘Sprint Goal’. Only after that we can talk about which items we shall have in our Sprint Backlog.

Kanban, on the other hand, is great for reactive type of work like call center for example. In call center we don’t prioritize up front, we don’t plan big. We only need to visualize our process and improve its overall quality. For such environments Kanban is great match and it is a good idea to use it.

Kanban is not Scrum, Scrum is Kanban

I often get question what is Kanban and if it is better than Scrum. So let us start with explanation of what Kanban is. It’s a very light method coming from ancient Japan and then popularized by Toyota. It has three rules:

  • Limit work in progress (WIP)
  • Visualize
  • Minimize lead time

That’s all. You can start with any process, visualize it and based on what you see improve the throughput and bottlenecks. It’s simple, it works. But you have to be really improving based on what you see. Companies are often going to Kanban because the change required by real Scrum is too painful. So they do some board (you can’t usually see much from it), and say we are done.

Because Kanban doesn’t really help you with implementation and mindset change, Scrum is so successful comparing to Kanban (I’m not saying that Scrum is simple, but the opposite). So if you truly think about the three above principles, you find out that Scrum actually embraces Kanban at many levels. So let’s go one by one.

Limit work in progress (WIP)

In Scrum we have Sprint backlog to fix number of backlog items / User Stories in Sprint.

It’s a common practice to say that each person can work at one task at a time. Once it’s done they can take another one. Two (and more) people can work on one task to make it done faster.

Successful teams work one UserStory at a time. As a team, they take one Backlog Item and finish it. Once it’s done, they take another one and collaborate on it.

Visualize

Sprint backlog is visible, defined, well understood.

Common practice is to have Scrum board to visualize sprint progress and help team members collaborate.

We make our backlog and priorities visible to everyone.

Sprint review shows the done functionality every Sprint.

Minimize Lead time

Sprint Backlog and Definition of Done is here to make sure teams finish working software each Sprint.

Scrum says the shorter Sprint, the better. So most of the teams now have two weeks Sprints and there is strong trend to one week Sprint.

Common Kanban/Scrum misunderstanding

One of the most common misunderstandings and reasons why people choose Kanban and leaving Scrum is that we can’t deliver working software any time during the Sprint in Scrum. We have to wait to the end of Sprint they say. But there is nothing in Scrum which would prevent you from continuous delivery. The only changes you need to do regarding team practices (note it has nothing to do with Scrum itself) is to adjust your definition of done (DoD) by adding “running on production server” and let team to work ‘one Story at a time’ so they deliver done functional stories one by one. Any time during the Sprint they are done with that story (done means it’s according to the DoD) the functionality is already at the production. Simple and straightforward 🙂 right?

So all around, there is no reason to leave Scrum. By the way, if it’s not fun to be Scrum, it’s most likely not Scrum, so inspect and adapt the way you work. If you are looking for some useful tools how to make it working and how to make it more fun, you can check my new book The Great ScrumMaster.

How to make your Retrospective great?

Retrospective is the crucial part of your success. Through Retrospective you implement Inspect and Adapt principles. Through Retrospective you learn and become better team, product group, and organization. So let’s have a look at a few tips about how ScrumMasters (but not only ScrumMasters) can make Retrospective great.

Understand the goal

The typical mistake in the beginning is that teams and ScrumMasters use the Retrospective only to discuss issues or complaints. The goal of the Retrospective is not to say what went well and what went wrong, but to improve. And in order to improve, you need to get clear list of action items actionable next Sprint as a result of every Retrospective. The frustration of some teams is coming from the fact that they can’t solve everything right away. ScrumMasters shall help them to find the first step and make sure they are able to make it. Then celebrate the success and find a next improvement. Don’t take too many action items. One, two or three are more than enough. Quantity is not the quality here.

Find root cause, don’t solve symptoms

Another tool which can help you to make your Retrospective great is root cause analysis. Too many times you spent time and energy in solving symptoms. The particular issue would got solved, but soon another two emerged. It’s never ending. Instead, whenever team identifies any problem, ask them to investigate it a little, why is it happening, when, who gets involved, what is the impact of it, what can cause it, etc. Once you understand it, in most of the cases you realize that the root cause is somewhere else then in the identified problematic situation. And more than that, once we address it, it solves many other issues we’ve been facing and didn’t know what to do with them.

root cause

Change the format of the Retrospective

Sometimes, even if you facilitate it right, teams are saying that they don’t get enough value from the Retrospective anymore. It used to be great but now we somehow lost the focus and it’s not that useful anymore. People are not coming with new ideas; it’s hard to identify any improvements. It usually happens when ScrumMaster uses the same format of the Retrospective all the time – i.e. “plus/delta”, or star with “Start, More, Less, Stop and Continue”. It became a routine. So here is the hint how to make your Retrospective again engaging. Every time you facilitate Retrospective, make it different. Use a different format, ask different questions. My favorite question is “What made you smile last Sprint? / What do you want to change?” You would be surprised like such a small difference change the energy of the meeting, brings different attitude and helps you make the whole retrospective in more creative environment. Once people get used to it, involve the whole team in designing the retrospective format.

If you find it interesting and want to know more, you can watch my conference talk on Agile Retrospective below or get my new book The Great ScrumMaster.

Organization 3.0 – How to Achieve Modern Agile Organization

Organization 1.0

Organizations are constantly evolving. In the 1970’s the most common organizational structure was the pyramid structure. It was deep, hierarchical, and full of power. Companies got strong bosses who lead such structure. Internally their approach was full of command and control, bureaucracy, and standardization.

organization 1.0Those pyramid hierarchical structures were not wrong in any way. They were the perfect solution to world industrialization and to the dynamics of business at that time. Most of the companies followed the best practices for a simple world, where problems can be classified as obvious, and applied a simple structure to address it. And it worked. Bosses got results. Companies started growing and became more successful.

IMG_0752The most common management tool was a carrot and a stick, because organizations believed that their employees are lazy slackers who can’t work without it. Most of the people were in a mood of tribal leadership 2 where the motto is “my life sucks”. Complaining all the time. Not happy, not motivated. Their only motivation to do something was driven by getting some bonus – a carrot, or because they were forced to – a stick.

Organization 2.0

Twenty years later, Organization 2.0 was here addressing the difficulty of the business world focusing on specialization, processes, and structure. Companies realized that the world is not simple any more, and the majority of problems can be classified as complicated.
As a result, they adopted complicated processes, focused on deep analysis, and invested in experts.

The belief in Organization 2.0 is that complicated problems need experienced individuals and detailed analysis. As a result, companies invested in learning and specialization. They began to grow. The work which used to be done by one person, now needed specific and dedicated positions. We’ve got a specialized department to deal with java, database, testing, architecture, analysis, documentation, customers, accounts, plans, and chair purchases.

organization 2.0Organizations are trying to create a process to describe everything, to have every possibility thought over. Companies create career paths and talk about motivation. They have spent months describing KPIs, but the more processes and specializations they had, the less responsibility and goal driven individuals they had. They were starving. They tried to cut on expenses, but that did not bring any long term success either.

So they dream about the previous stage, where it was much easier to manage resources. At that time, managers had real power. They could make decisions. They could force people to work. They could use the carrot and the stick. It was so simple – no need for committees, no need to call a meeting for every single detail. At that time, allocation of individual resources did not cost most of their time.

Leader-follower leadership styleThe pressure on individuals to make themselves more successful, better, and smarter than others was huge. “What if my colleague is be better in the performance review?” “What if I am not promoted in two years?” It leads to a culture that emphasizes own goals over the organizational ones. Most of the managers and experts live in the third level of the tribal leadership model, where they believe that “I’m great, but you are not.” So they treat their employees and colleagues with little respect or trust. This leads to the leadership style of “leader-follower”, where the managers decide, and the people below them just do the job. No initiative is expected. People just follow the process and do what is ordered.

Organization 3.0

Nowadays, when the world is not complicated anymore, neither Organization 1.0 nor Organization 2.0 can address its full complexity. We have realized that such complexity needs a very different approach that can keep up with business dynamics. The Agile environment brings Organization, 3.0 which builds on teams instead of individuals, on different styles of leadership, and on intensive collaboration through the dynamic network structure. We need to completely change the leadership style, create partnerships, enforce self-organization, enforce real responsibility and ownership, enforce trust and transparency, and build the organization as a network structure which is flexible enough so that it can effectively respond to change. Decentralization is taking over, and is bringing a certain level of autonomy to self-organized systems.

Agile Organization - organization 3.0

Instead of being a huge tanker, you can imagine the Organization 3.0 as a flotilla of smaller boats, going into the same direction, living in the same context, having the same values, but making some decisions differently based on the situation.

The Organization 3.0 is a true Agile organization. In order to build it, you need to apply a different leadership style of “leader-leader”, which supports growth of people, instead of “leader-follower” which is so common in Organization 1.0 and Organization 2.0. Hand in hand with this new leadership style, you need to create a culture of tribal leadership “We are great!” where the focus is not on the individuals but on the systems and teams.

Leader-leader leadership style

Organizations are complex, as they have to deal with people’s behavior. People are not predictable. Every time we tried to make them behave in a predictable way, we failed. A modern Agile organization is built from people. It is a collaborative, creative, and adaptive network. It’s a sphere built from autonomous systems which are connected to each other, so they influence themselves but still keep consistent. Such a change of mindset is a huge mental challenge for most organizations.

So how to start?

Modern Agile Organization
Modern Agile Organization

– Help all people to become better leaders by applying the “leader-leader” leadership style, and build a culture of tribal leadership: “We are great!”
– Decentralize, build networks and communities.
– Allow autonomy in a well-defined context.
– Read my book The Great ScrumMaster, which is a guidebook not only for ScrumMasters, but also for leaders of any organization who want to become an Organization 3.0.

You can see my talk Agile Organization – Organization 3.0 at AGILEEE Conference 2016: