Your first Sprint as a Product Owner

Scrum is getting more and more popular. And one role that doesn’t get too much attention is actually one of the hardest in my eyes. The Product Owner.

This blog is dedicated to help professionals grow their skills as Product Owners or start to become one. It is driven from experience of working more than 5 years as a Scrum Master together with Product Owners and being one myself fore more than 1 year. If you came here as reader of my old blog better change your bookmark since this will be the new address where I’ll provide you with content from now on. Together with my 2 partners in Oikosofy Vasco Duarte and Luis Goncalves we’re providing you with everything that you’ll need in your venture to become Agile, Lean and create products that matter and delight your customers.

Who is this for?

You’re brand new in the role of Product Owner or you’re planning to become one in the near future? Then this is for you. It also helps people new to Scrum to understand better what the role of the Product Owner includes and how what a Product Owner does in reality.

  • Product Owners
  • Scrum Masters
  • Leaders looking to use Scrum for their organisation
  • Anyone interested in getting insights to the role of Product Owners

ProductOwnerTeamStakeholders

Assumptions

For this rough recipe the following assumptions are used:

Sprint length: 2 weeks
Testing: mainly done manually
Team: collocated in one room
Stakeholders: All in the same location and country
Backlog: The product backlog is already in place and filled
Planning: A roadmap reflecting the current and upcoming sprints exists

In the next part I’ll describe some of the major Scrum activities as well as the specific Product Owner duties and activities. This is an exemplary list and kind of “by the book”. You’ll rarely find a Product Owner doing all these activities. But if you start doing it you should aim high, no?


Your very first Sprint as Product Owner

Day 1 – Sprint Planning

The Sprint always starts with the Sprint Planning. The Product Owner brings along the Stories that she has prepared beforehand and ordered in terms of criticality and business value to present it to the team and then together collaboratively create the Sprint Backlog. Depending on the preparation this can last from as short as 20-30 minutes to 2-3 hours (for a 2 week sprint).
The goal is to have a common understanding of the Sprint Goal, the scope of the sprint backlog defined, the Stories well understood by the team and Acceptance Criteria defined to be used at the end of the Sprint for the Sprint Review.

  • Set the sprint goal
  • Motivate and engage the team for a challenging yet doable Sprint

Day 2

  • working with Stakeholders to update Release planning and Roadmap
  • answering questions of the team
  • (optional: reviewing and accepting Stories)

Day 3

  • working with Stakeholders to update Release planning and Roadmap
  • answering questions of the team
  • (optional: reviewing and accepting Stories)

Day 4

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • working on the Product Backlog to prepare the PBR

Day 5

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • finishing the preparation for the PBR to fulfil the Definition of Ready

Day 6 – Product Backlog Refinement

In the Product Backlog Refinement the Product Owner and the team can clarify upcoming topics. These could be epics or features that haven’t been further analysed and need clarification. The Product Backlog Refinement is a good occasion to break Features down to Stories and add useful information to the Stories.

  • answering questions of the team
  • (optional: reviewing and accepting Stories)

Day 7

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • clarifying open questions from the PBR in preparation of the Planning

Day 8

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • clarifying open questions from the PBR in preparation of the Planning
  • working on the Product Backlog in preparation for the Planning
  • negotiating priorities for the Product Backlog with stakeholders
  • updating Release Plan and Roadmap with stakeholders

Day 9

  • answering questions of the team
  • clarifying open questions from the PBR in preparation of the Planning
  • working on the Product Backlog in preparation for the Planning
  • negotiating priorities for the Product Backlog with stakeholders
  • updating Release Plan and Roadmap with stakeholders

Day 10 – Sprint Review

In the Sprint Review the Committed Sprint Backlog will be reviewed in the form of running tested software. The Product Owner and team will check if the agreed Definition of Done is fulfilled for each Story and will reject Stories that don’t fulfil it.
The Sprint Review is an open event that everyone can join and especially real end customers can and should take part in it if possible.
The Product Owner as spokesman for the customers will decide what’s finished and can be released to the public and what not.

  • Celebrate with the team
  • Thank the team and give them a small pause to do the Retrospective and recharge batteries

What next?

This is an exemplary schedule of a Product Owner.
A Product Owner should always aim to have exactly the availability that the team needs to answer questions or review work in progress. Every hour that can be saved for reworking Stories that weren’t finished as “intended” during the Sprint is a big saving compared to do it after the sprint.

Managing the Stakeholders is a difficult task. Especially balancing the time used for meetings with stakeholders versus working with the development team. If you can get this right, you’re set up for success. Many Product Owners that I’ve worked with were swamped with meetings trying to please all stakeholders and left the teams alone during the Sprint. This is an anti-pattern that should be avoided.

If you liked this post sign up for more.
This blog will be a source mainly for Product Owners and related topics.
In future posts I’ll dig deeper in what you saw under Assumptions. E.g. creating your first Product Backlog and how to do regular Roadmap updates and Release planning.
In case you don’t want to miss out on that, sign up.

Sven Schnee

The 5 Pillars of an Agile Change Initiative

Hi there,

 

there are many reasons for changing to Agile or Lean ways of working. Keeping up with the competitors, huge problems in quality or maybe even doing it right from the beginning?

One thing that good consultants will be able to tell you is: it’s not about the methodology that you choose. This can be a factor but won’t be key to success.

So what do you have to do, what is it you have to consider?

Pillars of Justice
Pillars of Justice – Hindrik Sijens – flickr

  1. Methodology
  2. All-level management support & understanding
  3. The right setup
  4. Honest Feedback culture
  5. Continuous Improvement

I call these the 5 pillars. But before we go into detail about them, I’ll first describe you what happens to many of the unsuccessful agile adoptions. They focus on methodology. And methodology only.

1. Methodology

Step 1 – Choosing

It normally all starts with certain pain points that need to be addressed.

  • Quality is not sufficient
  • Delivery speed is not high enough
  • Architecture is “broken” and the software no longer extensible
  • Projects take too long don’t get finished and cost too much
After that the next step often is to choose a “silver bullet” to solve the problem.
E.g. Scrum as the “new project management framework”. Which it is not. It’s an empirical process improvement framework in reality which is a completely different thing.
Now with the Silver Bullet in their hands next thing

Step 2 – Adjusting

Trying to fit the Methodology to the status quo.
Whatever feels uncomfortable will not be taken over in the new methodology, the parts that fit the current environment will be adapted.
In the Scrum environment that often leads to teams doing Daily Scrums but no Retrospectives.
And Testing + Reviews are done at the end of the sprint instead of continuously and automated. This is called Mini-Waterfalls.

Step 3 – Depression

Partial or complete failure. Putting blame on the Methodology as not fitting and not solving the problems.
Why is that a quite common scenario?
Is it because the wrong methodology was chosen?
Would XP be a better solution than Scrum?
Isn’t Kanban much better than Scrum in certain situations?

Systems thinking is needed

Whatever methodology you choose, if you don’t address the pain points that brought you to your change initiative it will be fruitless.
This typically requires systems thinking:
  • looking at the big picture
  • visualising what is going on for the whole and it’s parts
  • fixing structural problems
  • having people who can see the whole instead of the small little cogwheels
  • e.g. identifying the testing problem and changing the whole testing approach
Methodologies alone are useless.
You might have heard the saying”a fool with a tool is still a fool”, this is similar.

2. Management support & understanding

This point is somehow obvious, since for any initiative you’ll basically need management’s support to get started. They need to provide budget to get Agile Coaching on board or simple give your team enough time to start learning on how to do Scrum and test automation.

But this is by far not enough to succeed.

Start by coaching the Management

The senior and middle management can be the single point of failure for any change initiative.
That’s why the change initiative should make management the engine of change.
First of all all levels of management need to understand how the future state should look like and why things will work better. They need to be the ones driving the change and working with their people, the Coaches should aim to educate them so that they’re enabled to do it.
This is not fast and it is not easy. Understanding concepts like Agile and Lean takes time and hard work. Reading books, working with it, participating in communities.
Nonetheless it’s essential. Someone who doesn’t understand or know the How and Why will inevitably take decisions that will block or negate the whole initiative.

Management Support

Now that the management is on board they can ensure:
  • Impediments that affect the whole organisation are worked on by upper management
  • structural changes that affect personell hierarchies can be done
  • that strategical decisions resulting out of insights gained in the change initiative will be better informed and faster

3. The right setup

Did you ever try to explain a concept like cross functional teams to someone that has either no clue of software development or worked in silos for 10-15 years? In either case it’s difficult. That’s why management needs to understand first how it can and should work. Only then will they support structural changes. And only if they know or learn what systems thinking is and how to apply it will they be able to take the right actions.
The organisation should be built around the value flow. Using tools like Value Stream Mapping and Kaizen Management will be able to change the structures where needed.
Changing organisational structure is a painful and costly process, which leads us to the next pillar.

4. Honest feedback culture

When organisations are changed to improve value flow this often results in roles or whole departments to get redundant. Especially for all people that are affected by this change it’s utterly important to get positive feedback and another role or position in case they are doing a good job.
And then there are those that didn’t really do a good job. It’s also important to be honest and transparent with those people, especially if there is no other role that they could fulfil in the new setup.
Let me give you an example to understand this better.
In Scrum a full team consists of Product Owner, Scrum Master and Team Members.
There are no hierarchies between the people. Everyone is equal.
Before you could have had a setup like: Product Manager, Project Manager, Team Lead, Developers, Testers. Product and Project Managers were telling others what to do, Developers were looking down to testers.
All the hierarchies and reporting lines that existed in the previous team setup will be eradicated with the introduction of Scrum.
This is especially important for all the middle management like Team Leads and Department Leads. They will need to be mentors and Servant Leaders in the new setup which is not compatible with a Command and Control mindset. So better be open and honest with them and go separate ways early instead of having them corrupt the change initiative. Identify and support all the Servant Leaders because those will help tremendously.
Which leads us to the most difficult and basically the only thing that will help you to succeed.

5. Continuous Improvement

Another word for Continous Improvement is Kaizen. This results out of Toyota Production System which was the start for the Lean movement.

Kaizen on Wikipedia: “When used in the business sense and applied to the workplace, kaizen refers to activities that continually improve all functions and involve all employees from the CEO to the assembly line workers.”

That’s exactly the idea.
  • Resolve problems immediately
  • Actively work to remove impediments
  • Never accept the status quo always strive to improve
  • built quality into all steps of the value chain
  • Aim for the impossible to achieve greatness
Not having a continuous improvement cycle will kill all change initiatives sooner or later.
It’s like doing Scrum without having Retrospectives. This is taking away the insights and learning part and makes it almost impossible to improve.
Combining all the pillars together leads you to this:
As you can see everything is building on each other and still the pyramid is upside down to visualise that continuous improvement is the key to success but won’t really work if you don’t have the rest.

In my experience Step 1 is done right by most companies.
Unfortunately Step 2-5 are barely executed by all those companies trying to get better.

Key to success is having all 5 Pillars in place or at least worked on. Any such initiative takes 2-5 or more years depending on the size of the company. If you’re struggling with getting any of the pillars in place get in touch with me or any of the other coaches of Oikosofy. You’ll find us at www.oikosofy.com
A good start could be to attend the Scrum Master Toolbox webinar. This is done by my appreciated  partners Vasco Duarte and Luis Goncalves. (@duarte_vasco@lgoncalves1979)

If you liked this blog post please share it with your friends or colleagues who might be interested.
You can also follow me on Twitter @MrSnow76 to get updated when I publish new blog posts.

Thx for reading,
Sven Schnee aka MrSnow76

Overtime hurts – Your company and Yourself

Welcome dear reader,

Have you done overtime in your life? Did you have that one project that meant a lot to you, and you really wanted to get it done?
Are you currently working 10+ hours?

Currently I’m working on a project and I know that every hour I don’t invest in the project could potentially mean failure. Failure would directly affect me since I personally gave my word to finish this project because I believe it can be done. It would mean dishonour, loosing trust and potentially severe consequences for people that trust me to get things done.

All good reasons to do overtime, no?

Overclocked and Overworked
Overclocked and Overworked © by Bryan S on flickr

“Working longer hours creates more work than it accomplishes”

This is a direct quote from Jeff Sutherlands newest book and it is completely true.
Thinking about why I’m doing overwork right now brought me to the conclusion that currently I’m not only damaging my personal life by working too much, but also the company I’m working for.
Let’s analyse a bit what I’m currently doing so you can understand this better.
For the current project I’m working as a Product Owner. And we’re closing in on the release date of the project. We’re supposed to work agile and we’re in the “stabilising and bug-fixing” phase.
Those of you who understand what “working agile” means already spotted anti-patterns in what I just wrote.
Right now my main duties are:
  • Writing Tickets to resolve Bugs and retesting them
  • Testing
  • Defining Test-Cases for manual testers
  • Organising test runs and all pre-requisites
  • Taking care of a sub-project that is critical for the projects success

Don’t do work that you shouldn’t do

Now as a PO I shouldn’t do a lot of what I’m currently doing.
If you know what a Product Owner is supposed to do you probably understand what I mean.
But why does this hurt me or the company?
The company is hurt because you’re compensating for a lack that actually the company should address. In my case the company should focus on getting better in testing to be able to deliver “done” functionality after each sprint. This includes a lot of work since the only way how to do that is automated testing and this requires a lot of learning on the team side.
But as long as this is covered by people that take this important role on them by doing it manually the company will not do anything. And the company should really do something here.
But much more important hurting yourself is much worse.
If you work too long you feel that personally through one or more of the following symptoms:
  • Feeling tired and exhausted
  • Not having time for your loved ones
  • Learning, Sports and other activities are things you always want to do “next week”
So if I work longer than 8 hours I’ll hurt myself because I cannot focus on other things that are important like Sports to give me more energy or learning  that will make me better in my job.

Be professional and make it transparent

If you want to be professional in your job this is something that you have to highlight.
This can start by saying NO, when you’re asked to do something that you shouldn’t do.
Now please don’t confuse that with narrow roles and the typical “this is not my job” statement. In a cross-functional team it’s the whole teams responsibility to get the job done.

But there are limits to this and you most probably know best where those limits are.

So whenever the limits are broken for yourself think about what you can do. Simply saying NO might not always be an option. But there are other possibilities:

  • Highlighting the broken system (in my case showing how the quality is not sufficient)
  • Talking with a sponsor, mentor or stakeholder
  • Giving suggestions on how a possible improvement could look like

Improvement – Everyone is responsible

Teamwork
Teamwork – by Ice Birdy on flickr

It should be the responsibility of each and every person in a company to improve. If you don’t get what I mean by that read this great blog post by @WoodyZuill to understand it better.

Whatever doesn’t work in your company shouldn’t be taken for granted. And everyone should be able and asked for improvement contributions.
This way if you find some dysfunctions like the one described above your feedback will not be treated as criticism or negative but rather welcomed and appreciated.
When you bring forward your idea of improvement start with that. Any leader who takes the well-being of the company serious should be more than willing to set some learning system up that will boost long-term improvements.
While reading this you could have thought about that one thing in your work that you have done for weeks or even months but always thought that it is wrong.
But there was never anyone to do it other than you.

Think about the long-term success of your company and answer yourself the question: should it continue like that or are there better alternatives?
If you have one or more alternatives find the right person to talk to and start improving TODAY.
There is no reason to wait any time longer. You’ve waited long enough.

I hope this gave some of you a little bit of inspiration to start improving.
I’d be glad to hear about your improvements in the comments or on twitter @MrSnow76.

Thx for reading,
Sven Schnee

Dear Product Owner, Scrum Master, Stakeholder or anyone else who needs to know when their project/release is finished,

in any project or product development there is a need of being able to know when your fancy new product is ready to go live or when your piece of work can be integrated with the rest.
There are many good reasons why you want to know when you’ll be done.
As we all know in traditional waterfall projects you always know when you will go live, sometimes years ahead, UNTIL the hidden monster of variability shows up and kills the deadline several times. Sometimes up to the extent where the whole thing gets cancelled.
In this blog-post I show you a different approach on how to keep progress transparent to ensure you can keep your deadline.

Variability kills Deadlines – and Projects

Ok so here I go, being Scrum Master of a fresh one year project and we got a new Product Owner that never worked with Scrum before and had a Waterfall career for 15-20 years.
We started the project and after 3-4 months senior management steps in to ask “where are we standing with the project, will we deliver on time within budget?”.
And the PO tells them he doesn’t know. So senior management tells him to create the full backlog of things that have to be done for the project and estimate them with the team. But better use only one or maybe two persons of the team, because that’s cheaper. 😉
So the guy goes off for 2 weeks and starts writing Stories after stories until there are 180-200 stories in the backlog. And he hands that over to 2 developers to estimate the whole lot of stories.
So after 2-3 days of going through all that stories and estimating them those guys come up with a whooping 1000 Story Points to be delivered.
So the PO came to me and said, tell me when we will be ready. And I told him “I don’t know”.
“You have a completely fresh team of people that never worked together before, it takes at least 2-3 sprints to settle the team and get an idea about their velocity. And even then this velocity is a very bad indicator to tell you if you will be done in time or not. There is a lot of work yet undiscovered that will completely ruin what you will create now as a graph trying to predict the future.
The guy continued his journey 1-2 more months until the team asked me to step out of my Scrum Master role and into the Product Owner role.

You can never accurately estimate what you yet don’t know

So my first course of action was to throw away the old backlog and together with the customer discuss on a feature/epic level what they urgently need and what can be left out.
On this rough level I asked them to order the features in terms of importance and value.
From there on I started to break those features down to “Vertical slices” (I’ll explain that in a future blog post). And to know where we are compared to where we want to be at the end of the project I created a Release Burn-Up.
The blue line (and y-axis) on top shows the number of work items to do (in this case stories).
The x-Axis shows the number of sprints
The orange line is the speed needed to reach the Go-Live date.
And the red line shows the number of items done so far.
As you can see the project was in deep trouble when I initially took over and created that chart.
The easy and secret ingredient to this graph is:

The count of Stories done per Sprint

Teams output can vary a lot, depending on unknowns, sickness, vacation and input.
Also stories can be quite different in size and complexity.
Here is the distribution of the stories for this 12 month project.
The average of all the 191 Stories done in all the sprints was 8,91.
The majority of all stories was 8 or 13.
Now you might wonder, why this team still had story points? #NoEstimate tells you to get rid of estimations, right? Story points were here used to tell apart big stories from properly sized ones. A story with 40 story points never made it into a sprint but was splitted in at least 2-3 smaller stories.
What you want to have for #NoEstimates is small stories that can be done in 2-3 days.

Stories done per Sprint

With  average sized stories the secret of this approach starts to work.
You are able to calculate the average of stories done per sprint to use it in the forecast of when you will be done.
As you can see in the graphic below the number of items done per sprint stabilises as the team stabilised and the collaboration got better.

The full journey

Now with all this information I was able to talk about scope, deadlines and re-plan the whole thing.
As you can see in the picture below there were regular corrections on the scope as well as on the go live date. If you can tell a customer, you won’t be able to get all of the scope Sprint 16 but we can deliver it after Sprint 19 do you want to keep the Scope and get it later or de-scope and get it earlier, you can have much better informed decisions.

What is the difference between Estimating and this approach?

Let me come back to the initial story of having the initial backlog completely estimated which resulted in a total of 1000 story points for all the things to do.
  • Over the course of the project many stories that were initially estimated as 20 story points literally “exploded” to 5-6 stories of 8-13 story points
  • Almost none of the stories were underestimated
  • A lot of stories that have been estimated were no longer needed
  • 6 months later of the initially estimated 1000 story points a whooping total of 1685 story points were finished, which is a deviation of 60%, which is actually not that bad for an estimation but would have been disastrous for the Go-Live of the project
  • Estimating costs time and money, in this example the initial estimated was more than one full week for one person and for it to be meaningful you would have to re-estimate after every sprint
  • Estimating doesn’t deliver value, no story is delivered by it, no customer would ever pay for it
Counting done Stories is much easier and much more precise than using estimates.
And much more important: it’s based on empirical data rather than weak attempts to predict the future.
 

All you can do is manage Scope

What I’ve learned from all the previous products and teams that I’ve worked with is that the only reliable way to ensure that a project or product Release is on time is to actively, aggressively and well-informed manage the scope.
Please have a look at the blue scope line in the “Release Progress over time”to see how the scope changed over the course of the project.
  • You can’t speed up teams by incentivising them or using the whip on them
  • The more people you add to the project the later it gets
  • Variability will bite you in the ass every time there is a chance for it

Before you start your next Project/Release

Think about what you already know about the work that lies ahead of you.
If it has many unknowns, but you have a stable team that worked together for some time and also a PO who knows how to slice the work you might want to start this new way of doing projects.
It will give you much clearer information and removes the hassle of doing the big specification up-front.
In case you want to learn more please read this and other blog posts of my good friend and mentor Vasco Duarte: The No Estimates principle: The importance of knowing when you are wrong
If you have questions on how to implement the approach feel free to add a comment or write me on Twitter @MrSnow76.
Thx for reading,
Sven Schnee aka MrSnow76

Size Does Matter – even when you’re Agile

Hi fellows,

during the past years when I worked with teams or organisations I often noticed that defining the size of requirements is something that many have problems with.

Now before I start talking about the world of Software let’s use a quite simple example.

Getting Food.  And to keep it simple we only use fruits now.

The fruit exercise

If you need to get food for one person things should be quite clear.
You’ll get one apple, a banana some cherries or grapes and you’ll be set.

Fruit Bowl

Would you buy 3 Water-Melons for a single person? Rather not.

To feed a single family you’ll need a bit more. So you’ll go for a big Melon, a bunch of bananas, bunch of apples some oranges and then you’re done.

Now if you throw a big party for all generations of your family from Grandpa until grandchildren?
You’d no longer think of single apples but count in crates.

Shakesgrear-120108-DSC_7491

Let’s think bigger. You’re organising a big party in your sports club and assume that 500-700 people are coming, it’ in 2-3 months. What would you buy? Do you have any empirical data to know what you’d need there? Difficult, right?

PacLease - Liberty Fruit T800 1

Enough of fruits. We’ll come back to that later.

Even in Agile Software development you do plan.
And there are distinct levels of planning.

5 Levels of Planning in Agile

Vision (1-3 years)

The vision is the reason why we are developing the next version of our current product(s). It gives guidance to all parts of the portfolio for long term alignment.

Roadmap – Portfolio (1/2 – 1 year)

Depending on the size of your company you might have a full portfolio of different products. Some of them might have dependencies between each other. Portfolio planning depends on the release cadence but is usually done less often than release planning.

Release (several per year)

The long term goal comes along with certain key elements that have to be created in order to achieve the goal. Those elements are analysed and broken down to be implemented in releases. I’ll explain what does elements are and how we call them in agile in a moment.

Sprint (1-4 weeks)

A sprint defines the amount of work that a cross functional team can do in the sprint cadence. Scrum teams usually use 2 weeks but the range is from 1-4 weeks.

Day

Even per day we do plan in Agile. You might have hear of one activity that is called the Daily Standup. In other flavours of Agile planning might even be done several times per day for example in Kanban when you focus on keeping the work in progress limit low and ship fast.

It’s all in how you size it

Have a look at the picture to understand the different artefacts of planning, their sizes and names.
This is not an official list and most of the names besides Story are often confused and used where they don’t belong.
But how does this relate to the 5 levels of Planning?!
What names to use in which context?

Rules of Thumb for Sizes

Below you can find the rules that I use when working with teams.
If you can and should use all of these in your working context totally depends on the environment  that you work in.
If you only have one team and no long term business objectives you could also only need Features and Stories. Some teams don’t break down Stories to Tasks, because their PO slices the Stories small enough to be implemented in 1-3 days.
When you work in an area where you need to do Portfolio Planning it is rather important to not confuse the different sizes of work items.
In Vision and Roadmap Planning often only the terms Feature, Epic and Theme are used.
This is done to hide the big complexity of having hundreds of Stories and to keep a good overview.
When you do Release Planning, you want to know when you get Features A, B and C, but you’re not interested about the Tasks that the team breaks out of the Stories.

A Story might be a Feature but not an Epic

Features and Epics for some people are the same. I like to distinguish them.
The format to describe any work item in Agile can be exactly the same: “AS A…, I WANT TO…, SO THAT…”. This makes it so hard to differentiate. This is why I like to use different coloured Post-It’s to signal what is a Story and what a Feature or Epic.
While discussing about a Story you might find out that it is too big to fit in a Sprint and therefore is a Feature, then you break it down into several Stories which you can then implement Sprint by Sprint.
One example for an Epic would be: “Implement checkout for a WebShop”.
This would break down into Features like “Choose payment possibility, provide delivery address, show confirmation page”.
Stories could be “Add paypal payment, credit card payment, invoice payment”.

What does all of that have to do with fruit?

So why on earth did I start talking about fruit?
Well, food for people is a concept that is much easier to grasp than sizes of requirements in Software development.
While it’s totally easy for you to define how much fruit you’ll need for one person it’s already a good bit more complex to find the right amount of work to do for one day or to correctly size a Task.To find the right amount of Stories for a Sprint is already even much harder compared to feed a full family with fruit.

When you think of organising a big party for 500-700 persons would you think in Single Apples, or bowls? Or would you rather directly buy crates?
This is the same in Planning Releases. You don’t talk about Tasks or Stories. You want to have Features/Epics done.

When you start with a long-term (2-3 years) vision. What do you do first?
No clue? Well you might start with breaking things down to sizes that you can handle like Themes and Epics prioritise them based on criticality, business value, cost of delay and put them in a flow.

And then you start defining the first Release where you break down Epics to Features and Features to Stories. From there on you do that continuously Release after Release adjusting your Roadmap as you go and reflecting the market situation and the constantly changing requirements.

I hope this gave you some insights into how work items are sized when you use Scrum.

Next time you talk about work items you know which term to use when.
And if you talk with someone that doesn’t get it point them here so they can read about it.

[53/365] ● fresh and tasty

Don’t mix apples with pears 😉 or Stories with Tasks/Features

If any of the concepts explained here doesn’t make sense or you use the terminology completely different leave me a comment or Tweet. @MrSnow76

Thx for reading,
Sven aka MrSnow76

4 days ago my Ex-company lost a great guy.

 

Let me tell you the story of him.

Almost two years ago he joined the company. Fresh, full of energy ready to change the world.
He’s a passionate guy, motivated, willing to learn.
He joined the company because he could identify with it, the Mission the values everything seemed to fit perfectly. And he wanted to learn from the great experience that others had aquired before him so he could grow and get better while working with people.

To give you a bit better understanding about the backgrounds of his decision to leave the company let me quickly introduce to you the 10 intrinsic motivators that have been called CHAMPFROGS by Jurgen Appelo.

Intrinsic Motivators

Curiosity
Honor
Autonomy
Mastery
Power
Freedom
Relatedness
Order
Goal
Status

His personal Motivators in priority order

1. Mastery -> Honor -> Curiosity -> Goal -> Relatedness -> Freedom -> Autonomy -> Power -> Order -> 10. Status

As an Scrum Master/Agile Coach in an ever-changing world it is incredibly important for him to stay up to date with the latest and greatest, this is why Mastery is the most important for him.
Honor in the form of being honest and open with the people he works with is one of his key personal values and non-negotiable like quality in Agile Software development.
Curiosity is the driver for Mastery, without it no continuous improvement.
Working without having a Goal is like trying to reach a Mountaintop without choosing the right path beforehand. It might get you there but is highly unrealistic.
Relatedness is extremely important for someone who works with people. If the way of how a Coach works and the content provided doesn’t fit the audience then it doesn’t matter how competent one is in terms of Mastery.
Freedom is one of the core values of Scrum and the agile way of working. Self-organisation is the expression of that. Thus it’s important for someone working agile.
Autonomy is closely related with freedom but should be a given in an agile environment.
Power is not that important, although being respected and heard is important as a Scrum Master or Agile Coach.
Order is a temporary illusion in an ever changing world.
Status in the end is the last important thing for him since leadership is always the result of the right behaviour and not the position in the hierarchy.

Why he couldn’t stay

Mastery – growing the individual was somehow supported but only on a personal level, not organisation wide
Honor – Being completely open and honest was not possible due to hierarchical structures and the lack of feedback mechanisms
Curiosity – He couldn’t do the things interesting for him since he always had to jump in where the fire in the company was burning highest
Goal – Even though goals were defined together with his superiors he still wasn’t able to achieve any of them since the companies needs were put before the individuals goals
Relatedness – this one was fulfilled since he got good feedback from the teams he was working with
Autonomy – Since he was mostly told what to do it was difficult to get things going. Often new ideas and improvements were actively blocked by management.
Power – the feedback he gave was rarely heard. So it was hard to improve anything
Order – the given order was pushed on everything that had to be done, even if it might have not been the right thing to do. He hated that.
Status – Even though his status rised while working in the company due to the good feedback, he still didn’t care since he couldn’t really achieve what he came for

So why did I share all of that with you?
Isn’t money and status a big enough motivator to keep knowledge workers happy?
As you can see in the example above, it is not that easy depending on the values and needs of each individual.

If you wonder who the guy was… it’s me. (don’t worry, I don’ think I’m great but it sounds better as introduction, no? 😉

I’d be interested to hear from your own experience how companies can do better in motivating people and also what you think about the CHAMPFROGS approach to define the intrinsic motivators.
Please leave a comment or contact me on google+ or @MrSnow76.

Thx for reading,
Sven Schnee aka MrSnow76

Bring your team to the next level

Todays blog post is about improving a team. Or specifically on how can one improve their team. I’ve created this little idea of a workshop together with a friend and good colleague @MMinigshofer

What is a team?

The definition of a Team on wikipedia is the following:

“A team comprises a group of people … linked in a common purpose. Human teams are especially appropriate for conducting tasks that are high in complexity and have many interdependent subtasks.”

But more than that a team consists of people.
And to be successful as a group sooner or later people learn that a group can only be as strong as its weakest member.

Therefore to improve a team the members first need to know one another.

Step 1: Learn more about your teammates

Game number 1 is about learning how your team members “tick”.

The game that you can play to do this is called Moving Motivators. It has been invented by Jurgen Appelo and he kindly made it available for free download.
So what is it all about? You can read it in detail in Jurgen’s blog but in short it will reveal to your team members what motivates you as an individual.
By just doing step 1 of moving motivators and laying down the 10 cards in priority order and explaining to the rest of the team why and what the things are that motivate you the team will gain a much deeper understanding about each other.
Read more and in detail about it in Jurgen’s newest Book: Management 3.0 Workout
I’d suggest to use this game as a warm-up before coming to the real challenge.

Step 2: Finding the weak spots of your team

Everyone wishes to have a team that can do more together as if everyone would be working alone.
This is why in the second game we’ll have a look at the team itself.

The Whole is greater than the sum of it’s parts

So how do we find out?
In his books The five dysfunctions of a team and Overcoming the five dysfunctions of a team Patrick Lencioni describes the basic principles and values behind teams.

And in the workbook he delivers 15 questions that you can go through with a team and answer them with the value per question that you can see in the picture to the right.

Now answering all the questions will yield to something like this:
On the right you see the individual answers summed up for the whole team.

For each answer the sum or average per question can be calculated for later.

With the table to the right all answers of each question can be collected together and combined.

What we want to get is an understanding of how the team is doing in each of 5 levels.
So for Level 1 we count together the sum of all points for questions 4, 6 and 12 and then divide it through the number of team members (in our example 5 people)

This leaves us with a number somewhere between 3 and 9.
Read on to find out what the numbers mean and how we can make sense out of that.

Step 3: Improving the Team

The values that we just collected and calculated are just numbers for the moment.
But we are now able to make sense out of it.
Lencioni gives this guidance:
A score of 8 or 9 indicates that the dysfunction is probably not a problem for your team.
A score of 6 or 7 indicates that the dysfunction could be a problem.
A score of 3 to 5 indicates that the dysfunction needs to be addressed.
The five dysfunctions if you wonder are in priority order:
  1. Absence of Trust
  2. Fear of conflict
  3. Lack of Commitment
  4. Avoidance of Accountability
  5. Inattention to Results
Depending on the points gathered through the questions one should work on the lowest scoring level but beginning with level 1 up until level 5.
Where there is not trust all problems with commitment, accountability and inattention to results cannot be solved.
Try it out with your team, it will give you new insights and might help you to improve.
If it did, let me know how it worked out and leave a comment.
Thx for reading,
Sven Schnee aka MrSnow76

10 Myths about POs

Hi dear readers,

today I want to share some of my latest experiences with you.
Right now I’m not helping teams to improve but I am the PO for a team.
Normally I’m working as a Scrum Master together and for a team and the PO is “on the other side”.
So being on the other side opens your eyes for a completely new perspective.

So here are the Ten Myths about POs that I hear and feel every day, when working as a PO.

Ten Myths about Product Owners

1. POs are writing stories and detail out everything the team needs

Either as a Scrum Master or a PO you most likely have heard the following in a Retrospective or on another occasion:
  • Requirements are not detailed enough, we don’t know what to do
  • Acceptance criteria are not clear
  • Stories are poorly written
  • We don’t know what to do
So, here’s the hard truth. If you expect a specification in the form of a user story that will help you switch your brain off and just do checklist coding, Scrum and Agile is not for you.

2. POs are working on the backlog 90% of their time and use the rest for Scrum Meetings

The product owner is the one who knows exactly what she wants and will formulate that as precise and crystal clear prioritised list of Backlog items.
Once a product owner is not meeting with the Scrum team in a Planning or PBR session or answering their questions she’s sitting at her computer to write stories and keep the backlog in shape.
Bad news is, there is much more about creating  a product than only writing stories and dealing with questions of the teams.
  • stakeholders want their attention and they will constantly want to change priorities and do exactly the opposite of what they wanted 2 weeks before
  • having different stakeholders with separate agendas will put the PO in a mediator role between them to find compromises that everyone can live with in the form of priorities
  • customers need to be involved in the feedback loop and their feedback needs to be heard and transformed into something useful for the team

3. POs are available for the team all the time

So the theory is that a PO should always be there for the team to answer their questions. The team is the one delivering what the PO wants so it’s only fair that they have her for dealing with questions, whenever they need.

Well in practice I normally see the exact opposite:

  • PO being rarely available for the team and mostly in meetings
  • POs that have more than one team often 2-3 and by this most of the time in Scrum Meetings with little or no time in between them to do anything important like talking with the team or working on the backlog

4. POs know everything about their product

Since she is the owner of the product, she has to know exactly what she wants. And she’ll be able to express that without the need to ask any questions.
New functionalities can be explained by the PO in a way that stories are only a small reminder of what needs to be done and to check after the implementation that nothing was forgotten.

On the contrary.
Often the PO will be able to tell what user value is at the end of an idea, but the way there is the same adventure for him like it is for the team.
The PO can be lost if the team doesn’t help with:

  • doing spikes and prototypes to get rid of uncertainty
  • requirements analysis, discussing the HOW of the story
  • wireframes, quick design sessions, whatever helps to get a good understanding about how to get the idea to life

5. POs are evil guys that stress teams to the max for delivery

Well, sorry this one is true.

6. POs and Scrum Masters are enemies by nature

Since the PO always will ask for a higher velocity the Scrum Master will always have to protect the team and tell them to go where the sun doesn’t shine.

What I’ve seen in reality is that both of the above don’t have to become reality, if the Scrum Master does a good job of coaching the PO. Having good practices to find out the highest business value and the right priorities will actually lower the stress on the team and make the PO’s and Scrum Master’s life easier.
But then there are these myths about bad scrum masters. But that’s a different story.

7. POs know how to be visionaries and guiding teams

Before a new product development is started there will be a ceremony. It’s called the vision gathering.
The PO will hold a speech in front of all the company alluring them with a sweet voice and painting wonderful pictures in their minds about the glorious future.
Well, how many real visionaries did you see so far around you?
This is by far the one thing I’m waiting to see in a PO.

8. POs are not needed, the team can do that completely alone

More and more teams in my surroundings don’t have dedicated POs.
Well a team CAN do without a PO, this is without a doubt. It’s like having a car without a driver. If the driver jumps out the car will move on for some time. With cruise control it will even keep the speed, but just wait for the first bend in the road.

Whenever I see a team without a PO I ask them to get one. Either from inside the team, from the customer, wherever it makes sense. Doing this on the side can work somehow for a small amount of time but not taking the role serious is a severe mistake that will strike back heavily.

9. POs are Masters in Agile Release Planning

Every PO knows how to do a Release Plan. They are used to techniques like Story Mapping, defining Minimum Operable Feature Sets and constantly updating the roadmap to help the team keep the big picture.

Most of the POs I’ve seen so far are able to get the idea of Stories. Talking about Epics and Features and creating a continuously update release plan confuses most of them.
If they are not young and open to new ideas but have “old ways” of working still memorised trying to put everything in a giant backlog and getting numbers on all the parts of the checklist will be the preferred way to go.

10. POs are Managing a Risk List and update it constantly

Each feature has a risk indicator showing how hard it is to implement and how likely the effort that was estimated will meet the initial numbers. Since there are no longer Project Mangers in Agile environments the PO will also keep a list of non product related risks together with mitigation strategies. Cost of Delay will show how much a delay per day or week of a feature will cost.

If you ever had a PO doing that, please put me in contact with them. I’d like to get to know them 🙂

To be a PO is a really hard job and involves much more than writing stories and order some post-its on a wall. So tomorrow if you go to work ask yourself how you can help to create a great product.
It is and always will be a joint effort. Get your hands dirty and support the product owners.
They are not evil

You’ll need leaders if you want to be successful

Assume you have implemented Scrum for one team in your organisation and achieved this:
  • Team knows, understands and follows the scrum ceremonies
  • Fully collocated and cross functional team
  • Technical skills are used (test automation, test pyramid, Continuous Integration  and Continuous Delivery)
  • PO is part of the team and highly available
  • Vision for the product is clear, communicated and understood by everyone
Then you have won. Right? Story ends here, all live happily ever after….

No?

Did you hit a wall on your way, even if you did everything right – on the team level?

http://www.enna.com/products/lean-posters/leadership-posters?limit=100

Leadership is needed

Traditional Management often stands in the way of an agile movement. Things like:
  • Controlling and reporting
  • MicroManagement
  • Missing trust
are actually working against self-organising teams.

So for a movement towards becoming agile Management needs to transform into Leadership with the help of one or several Agile Coaches.



Step 1 of becoming a leader – understanding the system


Management should start working on understanding the whole System of their organisation by visualising what’s going on. Visualising the whole value chain of a company is easier than most would think.
You can start doing that by talking with upper management and finding out what steps there are for starting new product developments or projects. See an example of a consulting company first draft of a value chain below.

Using Visual Management to make the value flow a company transparent

Step 2 – improving the system


Once transparency on the whole value flow is there a few things become obvious:
  • Impediments are identified 
  • Bottlenecks are found 
  • The need for organisational structure changes that support the value flow may rise

When impediments and bottlenecks are found on a company level the only persons who can remove those are the ones who can take decisions like changing the company structure or hiring new people. This is normally senior management or C-level. 

They should have a regular meeting facilitated by an experienced Agile Coach to work on these impediments and to remove the bottlenecks.
Often there is more work in the whole company than is actually good for it. See the pictures below to get a rough understanding what happens when you do too many things in parallel compared to focussing on getting things done based on clear priorities.

Step 3 – Pull instead of push

Once it is clear that having everyone busy is not actually the way leading to success the next steps for the new born Leadership are:
  • establishing and leading company wide improvement cycles
  • work is distributed by pull mechanisms instead of pushing it to people
  • a culture of stop & fix is created that puts long term improvements above quick fixes

Step 4 – organisational changes

People need to be intrinsically motivated. To put it in three words, they need Purpose, Autonomy and Mastery. This is the last and hardest step for any leader. Ideas how to improve that are:

  • Give people slack time and room for personal improvement
  • Abolish performance appraisals
  • Create Peer groups to help people improve and get feedback
  • Celebrate success on all levels (teams, departments/tribes/guilds, company)
  • Provide long term goals for the company that employees can align their own goals with
  • Develop exceptional people and teams that follow the company’s philosophy
http://www.americanfreedombybarbara.com/2013/06/nik-wallenda-walks-on-high-wire-across.html
Balancing out the approach to become Agile by working as much with management as with the teams is crucial to long term success. Focussing on only the teams or only the management will bring the whole movement to a stop before it could really gain momentum.
So don’t forget to get the buy in by upper management before you start implementing Scrum or any other agile methodology in your organisation.
If you made similar experiences of hitting a wall please leave a comment describing what happened for you. In case you haven’t involved management until now and want to help them become leaders drop me a call or email to start with a simple workshop to get them going.
MrSnow76

The cycle of decay in Agile

More and more projects and Scrum Teams that I work with show similar symptoms. This is why I’d like to share with you how I’m working with those teams to overcome the underlying problems and grow into something bigger and better.

Lets start with the Symptoms:

  • stories take much longer as estimated
  • a lot of rework has to be done after the stories are “complete”
  • quality is not sufficient, several bugs are found during testing
  • stabilizing sprints are needed after delivery to “get things right”
  • everyone is happily working until short before delivery then everything goes crazy normally leading to one or more delays in delivery

The cycle of decay

Reasons

  • Missing or part-time PO
  • Lack of collaboration with the customer
  • Lack of research and analysis of the PO together with the team
  • Proxy or “Fake-PO” who just doesn’t have the know-how to answer all the questions of the team, most often only a Project Manager in disguise

Jump out of the loop

http://activerain.com/image_store/uploads/7/9/1/8/1/ar131246472218197.jpg

If you’ve ever been in that situation you most certainly have seen retrospectives with the outcome of
“we need clearer acceptance criteria” or “backlog is in a bad state we need to do something about it”.

There is good news and bad news how to go about that.
Good news is that these problems can be solved over time and with effort.
Bad news is that without structural change you’ll not be going anywhere.
What does that mean in this context?
You’re Proxy/ or Fake-PO needs to learn how to do Scrum or how to manage a backlog in an agile way. If you can’t provide that know-how internally get it from outside by the PO joining seminars, conferences and communities.
Once the know-how is growing the PO will need to motivate the customer to do real collaboration slowly but steadily transforming the customer representative into a real PO.

As a wise colleague once said the PO is:

  1. The person who owns the Product
  2. Knows and understands scrum and is willing to use Scrum to do the product development

As you might imagine this is a process that takes some time. Depending on the know-how and skills that the Proxy/Fake-PO and the customer representative have this can last from months to years.

There is no easy workaround to get this right. Without regular communication and truly understanding each other the Scrum team won’t be able to deliver the “right” thing to the customer and there will also be no real transparency over when feature xy and the whole product will be finished.

In case you are in such a situation no matter in which role you are:

  1. start talking to the appropriate people highlighting the root causes of the cycle of decay
  2. in case no one believes you try to get help from an external Agile Coach to explain to situation to the right people
  3. get the Fake-PO to involve the customer in your backlog refinement sessions and plannings
  4. start doing proper backlog refinement sessions to find all your hidden treasures together with the customer
  5. set up a training program for your internal PO and get help to slowly but steadily grow your customer representative into a real PO
In case you liked that blog-post maybe you want to share it with your friends or colleagues?
Thank you for reading,
MrSnow76