The Spirit of Scrum

In the US, where I am, we speak of the spirit of Christmas. And while some people are a bit cynical about it, we think we actually see it sometimes.  It is meaningful.  And people do know what you are talking about.

In a roughly similar way, the spirit of Scrum is also real.

Some people think, it seems, that Scrum is mainly a set of practices.  And that is true, as far as it goes.

But the values and principles behind Scrum are probably more important.  This is related to how we coaches and trainers talk about how a person or a team or a company ‘gets it’.  When we say that, we mean more a real understanding of the values and principles.  Of the spirit of Scrum.

So, today I want to focus on three words: love, camaraderie, and adventure. I think all 3 of these feelings are key to successful Scrum.

By love, I mean the real but hard and tough affection and respect for people.  A willingness to accept both the good and bad about their full humanity.  A kind of love for the people in your team. (Not the ‘I love you, man’ of that famous commercial.)  And a kind of love for the customers.  That, for example, the Team deeply wants their lives to be better.

By camaraderie, I mean the feeling that, as Shakespeare put it, we are a happy band of brothers in war.  (Yes, the ladies are not excluded, of course, and might, in general, prefer a metaphor not so like war.  …a different metaphor for a different day.)  I mean helping each other, working together. And I mean a willingness to be honest with each other (‘I just can’t figure this dang thing out.’)

By adventure I mean the willingness to charge into the unknown of innovation. To try new things (a way of fixing an impediment).  To fail, and learn from it.  And, ultimately, a passion to overcome all the hard realities of life, and still get to the goal successfully.  In all the dimensions of success that are important.  Including treating all teammates as comrades and respecting what the customers really want and need. (For example, not sacrificing quality in a way seen as stupid by the customer.)

Wipe your glasses again, and see and feel the spirit of Scrum. It is in those 3 words; it is more than any 3 words.  It will make you and your team better.

Please try all of Scrum.

Scrum is a bare framework. It is very simple.

Scrum is not trying to be a full methodology.

Lots of people are doing Scrum-Butt.  “We do Scrum, but…”  And then they say…

…we don’t have a product owner.
…we change the length of the sprint often
…we don’t have a Scrum Master
…we don’t do a _daily_ scrum
etc.

I strongly urge you to try all of Scrum.  No Scrum-Butt.

Because I think more success will result. For you, for your team, and for your customers.

A simple definition of the bare framework can be found in the Scrum Guide or in this list.

If, because of impediments, you are doing Scrum-Butt now, this is ok.  Let me just ask two things. Try to fix the impediments.  And tell yourselves and tell others….”well, we are trying to do all of the bare framework of Scrum, but so far we are doing Scrum-Butt…”

Thanks. And I think that will help you and others.

Joe’s Agile Release Planning – New Version

I have posted a new version of the booklet.  Here:

http://agileconsortium.pbworks.com/w/page/57940361/Joe%27s%20Release%20Planning

It is free.  Hope you find it useful.

I hope you will leave comments or send me comments.

Summarizing Scrum (a list)

The more I think about Scrum, the more it becomes a Gestalt…a whole thing.  And it becomes somewhat misleading to talk about its parts.

One must do all of Scrum.  It you only take part of the medicine…well, you will not get the real benefit.

Still, we must talk about Scrum one word at a time. And, for reference and other purposes, we can simplify this into a lost.  A list as a basis for discussion.  One hopes these discussions lead to a better life for you, your Team and your customers.

Scrum was ‘co-created’ by Jeff Sutherland and Ken Schwaber.  Their definition of it, the core definition anyway, is in the Scrum Guide.

I have produced several versions of a two-page list of things that define Scrum. The link goes to my latest version (V5).

This list is based mainly in the Scrum Guide, and also discussions with Jeff Sutherland and much reading and experiences.

The first thing to note is how simple the basic framework of Scrum is.

Secondly, you will note my bias, which is that the ideas behind Scrum are at least as important as the explicit Roles, Meetings and Artifacts of Scrum.

The items in brackets [ ] are things that are not in the Scrum Guide. I believe all of  them are ‘supported’ by Jeff Sutherland if not others.  So I do not feel I am adding unfairly to Scrum. But they are not all required to be doing ‘the bare framework of Scrum’.

Is release planning worth it?

In a word: Yes, if done professionally.

How is release planning, and release plan refactoring…how are they useful?

A few ideas:

• It enables the Team to share ideas
• It allows the Team to see the same elephant
• It enables knowledge creation
• It enables cost, benefit, time trade-offs to become apparent
• It enables everyone to start to distinguish minor decisions from major decisions

Any professional also knows that planning is not and never will be perfect. So, we must put areasonable time box on doing the planning.

It is also useful to plan with good ‘agile’ people. Meaning people who will use the information developed from planning in a useful way (eg, will not do the ‘stupid waterfall manager trick’ of expecting the Team to always hit the date they planned on Day Zero).

Let’s talk about this last one (minor versus major)…

To put things simplistically, there are two types of decisions, which I will call minor and major.  Minor decisions has a minor cost if we make them incorrectly.  If we are clever, we soon learn that we are wrong, and we correct the decision.

But some decisions are major. To change the decision later, it can be very costly in terms of money or time or reputation or some other factor.  Once we identify a major decision, we want to do our best to decide it correctly.  This means first being sure we have framed the decision question correctly.  Then, assuming this is a difficult decision, we want to make the decision at the ‘last responsible moment’.

***

Can planning be useless or worse?

Well, of course.  If you have people who will not learn.  If you have people who will take longer than the current knowledge can justify.  If you too many people who want to use the information for ‘stupid waterfall tricks’.

But if done with good people, using useful concepts, the Scrum Team (and others) can learn a lot doing Release Planning, followed by Release Plan Refactoring every sprint.

It is also true that we can learn by doing ‘real work’.  This is not to say ‘do only real work’…but one balances and shortens release planning (release plan refactoring) in the knowledge that we can and will learn some things faster by doing real work.

Who is Scrum For?

A few months ago someone I know and respect in the Agile community said that they do agile to make the world safe for programmers.

This phrase as stuck with me. I don’t know how seriously the person meant it. I suspect it was partially a joke and partially a stronger statement than one might think.  I suspect it is a real driving force for that person.

And it is true that many implementers have had terrible lives, at least often, and making the world better for them is a very good thing.

But I think we should strive for more than that.

We need to make the world better for everyone.

For example, the customers do not want software (usually), they want something useful that will make their lives better.  The managers need a better life.  The project managers need a better life.  The business owners need a better life. The testers need a better life.

Everyone around or affected by Scrum should be getting a noticeably better life.  And one easily noticed, in terms of the improvement.

This is happening, although it is not happening as much and for as many people as it should. And when it is happening, it is not being noticed and celebrated as much as it should.

Why?

Well, I think one fairly important reason is that too many of us are being selfish.  For example, we are so afraid that the programmer may have to work and be modest and admit failure, that we disable the mechanisms (velocity and demos, for example) that enable the customers and business people to collaborate with the Team.

Anyway: It is an odd request. We want everyone’s life to improve at the same time. No trade offs.

Can it be true every minute?  Well, perhaps not.  But can it be true every sprint, looking back at the sprint in total?  Yes, I think so.

Joe’s Agile Release Planning

I have written a new booklet that I want you to have (I think you will find it useful) and also to comment on.

It is about Agile Release Planning.

It proposes that agile release planning consists of these major steps (at least):

1. Assemble the Team and some business stakeholders
2. Agree on the Vision (of the release or maybe more)
3. Create the Product Backlog
4. Determine the Business Value
5. Estimate the Effort
6. Consider Risks, Dependencies, Learning, MMFS and other factors
7. Order the Work
8. Do the scope-date trade-off
9. Finalize the initial plan
10. Consider the ‘communication plan’

Note that the purpose of the work is not focused on the release plan itself. The most important purpose is the Team together with the business stakeholders start seeing the same elephant.

So, I wrote a booklet to show and explain how I teach teams to do each of these steps. And to address some of the ‘lessons learned’ in doing this approach in the real world.

I hope you will read it and comment. Please download it here. It is 28 pages.

Two Levels of Agile Planning

Almost all firms that I work with have at least two levels of planning.  We can call them “high level” and “team level”.

High Level                     

At the high level, project or product ideas come in.  Someone has to prioritize these opportunities initially, to see which ones make the cut.  Often this is formally done once a year (not our recommendation).  Often this is done by a small group, sometimes called a committee.

Depending on the size of the organization, high level could be for the firm, for the division, or for the department.

The committee considers the benefits and the costs and maybe some other factors. Sometimes the benefits and costs are formally calculated, and sometimes they are just ‘discussed’.

But usually, the committee comes up with a 1 to N list of projects that should be done ‘soon’ (again, often this means in the next calendar year).

Some recommendations to make this more agile:

• Do it with greater frequency (eg, every month for the Top X projects)
• Expect the numbers to change over time
• Make the numbers explicit
• Do as ‘team knowledge creation’
• Get feedback
• Consider how accurate it is, can be, and needs to be

Team Level

We believe every project should go through ‘release planning’ after it has been assigned to a Team.

The Team should do release planning again (it is like what the committee did) for the following reasons:

• it is being done at a lower level of detail, on only high priority wor
• time has past, so information is likely to have changed
• the Team needs the detailed information
• it affects Team motivation
• it enables everyone on the extended Team to get on the same page

We also recommend that the high level results of the Team release planning should be given as feedback to the committee.  The committee may have questions and may raise issues that the Team neglected to consider.  But more likely, the committee will learn more about how badly they mis-estimated or mis-understood the work.  And this is useful feedback for them.

Something Unexpected

What do we do when something unexpected happens?

“The readiness is all”, said Hamlet.

And so must we be ready. Not ready to be fools and become silly. But ready to meet that new thing, that innovation, that crazy idea, that new person…more than half-way.

Yes, we may be skeptical. Yes, as Polonius says (careful grandmother that he may be)…we must try our friends well before we truly take them in. [Note below.] And so we must also for innovative ideas.

But first we must be open to them.  We must take a risk. And try.

As many a Zen Master has tried to open many a student’s mind to satori.

This all comes to me by way of a new friend made last night, rather unexpectedly.  Well, completely unexpectedly. We were forced together, sitting beside each other.  Rather than sit in stony silence (as they say) we talked.  Exactly why or how it happened, I cannot explain.  And, while I deserve little credit for it, it was an amazing and far-reaching conversation.  Very satisfying on many levels.  I will take some credit that I let it happen. And in part it happened because I had no expectations. I asked and said what I wanted to say at the moment…but I was not trying to win or convince or do or accomplish anything.  Well, occasionally I wished to be polite and kind and teasing (as some of you know, I like to tease my friends). But mostly I had no big goal, except to learn and discover.

And later, I was sad. Not sad to have had the conversation, but sad that it had ended.

So, I give myself that credit. And I take it away too. I did not follow up well. The friendship made, the conversation started…  But it may never happen again because I probably have lost contact.  I was too polite.

And this is true of our ideas about innovation as well. We must have the idea, let it in, remember it, and then do something about it.  See if it will fly.

So here and now. A moment to imagine in your mind the blue birds of your happiness. May they fly. Wonderfully.

***

Note: The reference above is to the famous speech by Polonius to his son Laertes, which I have copied here.  Polonius is of course proposing that his son be far more careful than I am suggesting in this post.  I am suggesting more openness, more readiness.  But I am not proposing that we be careless, either.

3 Methods to increase Business Value

Yesterday I enjoyed talking to Southern Fried Agile, the local one-day agile conference.  My topic was this: Three steps toward greater business value.

I was also pleased to see that many participants said they wanted to talk about this subject. So much so that the organizers decided to run the session twice. I am happy that this is considered an important subject. Certainly I think it is.

Some things we already do in Scrum to increase Business Value (or should do):

1. Better partnership between Business and Technology
2. Improve the Product Owner (and give him or her this job)
3. Use a prioritized Product Backlog
4. Order the Product Backlog to maximize the release of Business Value (over your chosen time frame)
5. Build working product each sprint (if we get cut short, at least we can field what we have so far)
6. Demo working product and get feedback from business stakeholders each sprint. Ex: “Did we build for you the most value stuff this sprint?”
7. Release more frequently

Could we be doing each of those better?  (Ok, sorry for the rhetorical question.)

In the presentation, I suggested three “big” additional things we could do.

A. Business Value Engineering…

This is a framework for continuously getting better at delivering business value. By mapping the process, by articulating the underlying assumptions, by taking a fact-based approach to proving which improvements would be better.

B. Priority Poker

This is an easy thing to add to Release Planning or to Release Plan Refactoring. Or relatively easy. You enable the “5″ best people on business value (in your specific domain) to learn from each other more about business value. By voting “business value points” on each user story.  And the rest of the group learns too.

C. The Pareto Idea

This is classic, and in some sense, almost everyone does it already.  Except they don’t do it enough. And they don’t take it as a basic, everyday, mindset.  So, we fight every day to separate more the gold-platinum-diamonds from the silver-copper from the dirt.

This is a lot of hard work, every day, that we do while we break down the stories into small sprint-sized ones. (I like about 8 stories in a 2 week sprint.)

***

There is much more to all 3 of these ideas.  To be discussed later.  But they attendees seemed to like the ideas. But the real question is whether they got enough to start taking action (if only to learn more).  We shall see, I hope.

Agile Release Planning is not about the Plan...

The past week and a half, I have enjoyed working in France.  I have worked with 3 different companies, and a bunch of great people.

In the third class, we did a 2-day workshop.  The Workshop was mainly about agile release planning. With the real work of that company and those teams.

As with most people, some of the people were waiting. They wanted to wait to do the plan.  They wanted to wait until everything was known.  Until at least much more was known. And, as they know, the Plan would be better if they knew more.

This is a very normal human reaction. (And this group was not unusual in this way.)

But this is not the way of life.

Life changes, we learn.

We must always be changing the plan.  So, we do not do Agile Release Planning to have one Plan.  We start Agile Release Planning now, while we are relatively dumb, so that we can learn, so that we can discover what the plan will become.

And we want to discover that with the crazy human beings that we are working with (the Team) and working for (meaning: the customers).

I say 'crazy' in a most affectionate way.

Crazy in a nice way, crazy in an inexplicable way, crazy in an emotional way.  Crazy in far more ways than we have understood yet.  Because what it means to be human, to be a customer, a teammate, a friend, another stranger on the road…what it means to be this we still do not know.  The customers and the teammates are, for so many reasons, both good and bad, changing all the time.

So… we do some planning, relative quickly, and we ask our co-workers to work with us, and help us figure out what we are doing, and how we shall do it.

Lesson 1: We plan now, even with very imperfect information. And then we evaluate, and think about what we need to make a better plan.  And we do some of the work, and then we learn more, and re-plan.

Let me also add this.  Sometimes it can be true that, before taking a path, some things must be known. Or at least...if we choose one path wrongly, it may be hard to change paths later. So, we want to know more.  If you are convinced you have this type of situation, you have a much higher need for more information early.  So, use common sense.

But we caution you. At least with a software product, and with many other products, from experience we guess that you are again using one of the standard rationalizations for procrastination. "I need to know more first."  Analysis paralysis, as it is often called.  Almost surely, yes, review what you know now, but then learn from taking action.  The school of hard knocks is a wonderful teacher.

Comments?

Choosing a Scrum trainer/course

This is a question I get from time to time: How should I choose between one course/trainer and another?

This is an important question and deserves some thought.  It does not deserve, in my opinion, a simple answer, as one might get from Zagat's about a restaurant. The choice is very much different than choosing yet another restaurant.  For most, this is a once-in-a-lifetime choice.

The good news: Most people (I'll say 95%ish) are happy with their choice. Or so I hear. But did they make the best choice for them?  Very very hard to know.

Here are some criteria for you to consider. I believe you can think for yourself once you have some context or framework (a key Scrum theme).

1. Date, location, price. Yes, of course. You may think I am biased, but of those, by far the least important should be price.  Because in relation to the benefit, it is trivial.  OK, these three were obvious.

2. Course/workshop goal.  Yes!  What is the real goal of the course and the goal or goals of the instructor.  Even though they all say "CSM course", they do not have the same goal(s).

My goal is this: I want results for the attendee, for the team, for the customers.  To me, those results are the only things that count.  But I am sure many other CSTs (trainers) would say something different. Or would not agree.  Or would at least word that challenge differently.

3. Instructor personality: Yes.  Trainers have different personalities. And this affects how you learn.  How would you learn about this?  Well, one way is to read the trainer's blog. You might want someone who is the opposite personality to you.  Interesting ideas.

4. Instructor background: Not simple.  But if you are in finance in NYC, you might want a trainer who knows finance in NYC.  And a zillion other examples.  It can also be argued that, other things equal, the buyer should get it from someone who is from a different background. Maybe.

5. Instructor teaching approach: Each trainer has a somewhat different teaching style. To give an overly simple example: some use mainly a slide deck, some have no slide deck at all.  One related idea (theory): the training style should match your learning style.

6. Experience with Scrum. Some instructors have more experience with Scrum than others.  Jeff Sutherland and Mike Cohn would be good examples of that.  They have been doing Scrum for many many years.  (Oh, you thought I would only recommend myself?  Wrong.)

7. Accuracy of describing Scrum.  Umm. Some trainers understand Scrum better.  I do not know how wide the divergence is amongst the Scrum trainers.  I do know you will not hear the same thing from each one. Even about what I call 'the bare bones of Scrum'.  And certainly not about what things to add to 'the bare bones' to make it work better, but maybe that is different than 'accuracy of describing Scrum'.

8. Ability to explain the 'abstraction' of Scrum in a way that seems (is) do-able and practical in your specific situation.  Umm. Seems pretty important, right?  And yes, it is related to some of the other things already said.  But it is different.  One suggestion: read the trainer's blog.

9. Workshop or not. My colleague Catherine Louis got me, against my better judgment to try doing a third day Workshop. So, now I do that all the time. Most Scrum trainers do not. Or they do a different kind of thing.  In any case, that is an important part of the choice, in my opinion. Suffice to say that I think the Workshop is very valuable, based on feedback from the attendees.

I am sure there are more criteria. But that is a good start.

One thing I suggest you not pay attention to....

First, there is a thing called NPS (Net Promoter Score).  It is used a lot on normal products, and many smart people (not all), think it is very good. I usually mention it when talking about the Business Value of products.
First, I think the course/experience/situation in a CSM course is very different from a normal product.

OK. Some trainers gather an NPS score. From attendees who have just completed the course.  I do this also. (For me, I find the information somewhat useful.)  Each trainer attracts, for many reasons, different kinds of attendees.

If you get a chance to compare NPS scores across trainers, don't.  You do not yet have enough information to compare those numbers.  After you have taken the course from both trainers (of course, the first trainer will bias your observation of the second), you will almost have enough information to compare the NPS scores between both those classes.  If you could see only the NPS for each course (and both trainers would likely show those numbers to you, if you asked).  But NPS numbers averaged over a year's worth of courses will not be meaningful.  To you (although perhaps a trend line might be meaningful to each trainer).

In general, for all the trainers I know, the NPS will be high, and the differences between the NPS scores will not be meaningful. Certainly compared to other factors.  IMO.

Hope that helps. Interested in your comments.

***

The Team and the Implementer Role

There has been, in several places, some good discussion about the roles in Scrum.  And soon the discussion turns (explicitly or implicitly) to 'what is the Team and what does it mean?'

The Team

The full team is what is most important.  Product Owner (PO), ScrumMaster (SM), and Implementers.  Together.  About 7 in total. Ideally 100% dedicated to one set of work (one vision, one product backlog).

They will be motivated, responsible, pigs (in the chicken and pig story), etc.  They will help each other, self-organize, become a strong complex adaptive system, create knowledge together.

If there are problems, it is clear where the problems lie. (Maybe in the Team, maybe outside. But clearer.)  And clearer who or what is affected by the problems (the Team is less effective in building the product).

It is where business and technology meet. And most of the biggest issues are resolved where business and technology meet. (Ok, a complex statement that I will not fully explain here.)

It is this (full) team that wins or loses.  (Yes, a Scrum team can lose.  This is not a failure of Scrum. And Waterfall would not have been better.  Just longer.)

Key Issue 1 - PO part of Team?

There is justified concern, based on experience, that if the PO is part of the Team, he will force the Team to commit to more stories in the Sprint than the Team should.

Well, yes, this has happened. And many other dysfunctions can happen with any set of people, no matter how you configure them. But it should not happen.

First, the PO is typically involved in the process of getting the stories done each sprint.  He provides, or should provide, the business value information and the detailed requirements in a JIT (just-in-time) or flow way during the sprint.  Example: When the implementers ask questions during the sprint (and they always should), the PO should get an answer ASAP (if not sooner). [I also favor the Agile Spec idea, where a mini-spec for each story is ready JIT before the Sprint Planning Meeting.]

Second, the PO gets one vote amongst 6 or 7.  So, the other implementers should be able to out-vote him if he gets too crazy.

Third, let's take an example where the PO will be on vacation. If that case, the PO might say: "We should not sign up for 7 stories, we should only sign up for 6 because I will be on vacation one of these two weeks." So, the PO's input could be valuable that way.

Fourth, I find it is often the implementers themselves who over-commit. And the PO who wants and needs them to be realistic.

So, thinking of the Implementers (only) as the decision makers on the Sprint commitment is typically not that useful.  But, agreed, when we have the dysfunction of the PO trying to get the Implementers to over-commit (I do, sometimes, see that) it is wrong.  But that dysfunction can happen in any case, and mere talk about that 'Dev Team' as distinct from the full Scrum Team will not help much at all.  I find.

Key Issue 2 - "The Dev Team" idea

There is a lot of talk in the Scrum community about the Dev Team, as distinct from the full Scrum Team. (The Dev Team only includes the Implementers, is the idea.)

I find this way of talking, this use of words, generally unhelpful. Confusing, especially to beginners. And confusing later.  (We often have to ask: "Did you want me to call the full team or just the dev team?  And why?").  And just not very helpful.

Yes, the implementers do things 'together' some and talk just amongst themselves.  And I think we can say it that way.  If I want to say it quickly, I call them "the Doers".  Just two syllables in 'doers.'

Should they have an SM or a PO in some of these discussions or in this work?  I find it virtually universal for the first two years that the SM and PO are not involved enough.  In part because people just are not used to thinking about them.  It is a paradigm shift.

The Dev Team idea perpetuates the notion, to some degree, that there is still a concept of a 'technical success' distinct from a business success.  And that is not good.

There are only business successes.  I hope we have recognized that.  We deliver business value or we do not. Or more or less business value.  But "well, we did what we said we would do, and it is real neat technically" are both fairly useless notions.

Result 

So, you can see that the phrase "Team" (meaning the Team role that much Scrum documentation talks about) or "Team Role".... I don't like either of them.  Again, to me they are more confusing than helpful.

And you can see that I strongly feel that the issue of whether the PO is part of the team is also fully settled: Yes. (This is discussed in two earlier blog posts.)

Now, what I am talking about above is how we learn and how we teach and talk.  But in the end, the words are not that important.

The real question is always: what did we do?  What did we accomplish?  What shall we do?    The words can help or hurt a bit, but if you are acting the better way (despite always having some problems with words), then things are pretty good.

The PO - The Team - Daily Scrum

I have some different views on this, and wanted to share them.

Your comments are of course welcome.

I am NOT asking what is or should be in the Scrum Guide. Or whichever 'scrum bible' you use.

I am just saying what my thoughts and experiences have, together, taught me.  I want to discover just what is most effective for 'pretty good' Scrum teams.  (Maybe not best for super teams or for beginner teams.)  So, I am trying to have a conversation -- maybe about what to add to Scrum -- not a religious war.

OK.  My views expressed too quickly:

1. The PO is very important to success.
2. Understanding business value and understanding detailed 'requirements' is very important to success. Both these 'activities' are extremely difficult.  Both for the PO and for the Team.
3. Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
4. The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
5. The PO is definitely a member of the Team.  Given real life, often 100% of his time is not enough (see also #7 below).
6. The only team that matters is the full Scrum Team.  It is this team that self-orgs, most importantly. (Yes, every person, pair, teamlet self-orgs....not the most important aspect of self-org though.)
7. I do not think it is useful to talk about a team within the team. (I hardly ever say 'Dev Team'.)  Talking about a team within the team  creates an us-them attitude. And anyway is not useful. And at first at least, a bit confusing.
8. The PO must spend a lot of time with 'people outside the team'.  I will call them, at times, customers. managers, business stakeholders, etc etc.
9. Still, the PO should attend the Daily Scrum as often as possible (by phone if not in person).  And should answer the 3 questions. His work affects the output of the Team.
10. The simplest example is: On Day 1, a question is asked by the coder. On Day 2, the PO can give the answer (or at least say 'I got the answer') in the Daily Scrum.
11. If the PO does not do the Daily Scrum (ever), I think most team members start to think or feel (sub-consciously): "who is that guy; he is not part of the real team".

OK.  This is my experience.  Maybe limited experience.   Maybe just bad thinking.

Imagine that you disagree.

Where we differ, I expect my main reaction or push-back would be: "Well, I can see that happening, and it has happened to me, but I think we should coach them to be better, and often, if we coach them to be better, they actually will be."  Meaning for example: They can do the things above, and it will make them at least a bit better.

Certainly some of you have done different things and been successful.  But could you have been more successful doing it this way?  Or might 'my' teams be more successful doing it your way?  This, to me, is the question.

Again, I am not sure I would coach all beginning teams do it this way.  I am sure some super teams might be more successful another way.  My inquiry is: For most 'good' (but not super) teams, which is the best way to do these things? (PO, Team, Daily Scrum)

Of course, there are many other things in life and in Scrum than just the 3 things I discuss above.

BTW, while what I am saying above is not exactly how it is described in the current Scrum Guide, I do not think it is contrary to what the authors would want.  But it may be more than 'the bare Scrum framework'.  The minimum that they want.

Joe's Booklet on Agile Release Planning

I have a first draft, version 1.01 of a booklet that ties together all the posts I have made (well, most of them) on agile release planning.

Here: http://agileconsortium.pbworks.com/w/page/57940361/Joe%27s%20Release%20Planning

It is a bit rough, needs more editing. My apologies for that.

If you have a moment to read it or just look at it, and give comments, please do.

Joe

Refactoring the release plan

At the end of the last post, we had complete the initial release plan.
What were the key outcomes?

[This is one in a series of posts about release planning. See here.]

Well, the plan had some sort of scope, date and budget. Usually on Day zero the quality is 'crappy' to use the technical term. As it must be, given how much we don't know on Day zero.

The real win was that we now have 'everyone' on the same page, at a useful middle level of detail: what is this elephant?  What are we about to do... 

And then we start the first sprint.  Or more specifically, we start the first Sprint Planning Meeting.

But that is not really the end of release planning. But the beginning of RPR (release plan refactoring).

It is absolutely fundamental to agile release planning that we refactor the release plan frequently. I say (and many others that I greatly respect say) that we must refactor the release plan every sprint. Every sprint.  Ok, maybe during every 10th sprint there will be so little change, that we don't have to change the release plan at all.  Ok, maybe this very occasionally happens. But at least we must evaluate that that is the case.

Now, when I say release plan refactoring, I mean all of the following:

* changing the vision (all of these are 'if needed')
* improving the product backlog items (more, fewer, smaller, better)
* re-evaluating business value (very key and very hard)
* Re-estimating the effort (eg, where Story Points are wrong, for new stories, for newly sliced stories, etc.)
* taking a new look at the benefit-cost ratios
* including new learning about risks, dependencies, learning, MMFS, etc.
* re-ordering the work
* doing a new scope-date trade-off.  Usually to make the initial release smaller (fewer aggregate story points -- is one way of expressing it).
* including the newest velocity expectations (based on recent trends).
* adjusting the buffers and communicating the new, new release plan (scope, date, budget) to the right people

Now, I also include in Release Plan Refactoring all the changes to the Product Backlog information to make it ready for the Team to be successful in doing the Sprint work.  Some people use phrases such as 'product backlog grooming' for this. (Note: I think 'product backlog grooming' can have other meanings too, depending on who is using the phrase.)

These activities include:
* breaking down stories or epics into small sprint-sized stories.
* improving the stories or PBIs (wording, INVEST criteria, etc.)
* estimating the business value of the smaller stories
* estimating the effort of the smaller stories
* answering questions from the Team about the expected sprint stories
* adding detail (notes, acceptance criteria, etc.)
* adding an agile spec for each PBI to be in the next sprint.  [Sometimes this may be done 2 sprints or more ahead. But not 'way' ahead.]
* checking that the Team thinks each story (likely to go in the next sprint) is 'ready' before the Sprint Planning Meeting

One could argue that release plan refactoring and product backlog grooming are completely different.  I think this way of thinking is unhelpful.  One of the purposes of release planning is to make the work in the sprints more successful. Release planning is not completed until, for each sprint planning meeting, we have 'the stuff' ready for a successful sprint planning meeting. Among the key success criteria of that meeting is: we used the time of the business stakeholders well.

Let me pause.

Why is using the time of the business stakeholders important?

Well, they are the key independent check on the thinking of the Product Owner.  We know from long experience in our industry that 'knowing what the customer wants' is extremely hard. Extremely. The business stakeholders are people whose time is scarce and yet these people are essential to us in getting a much better fix on what the customer really wants (or what the firm wants).  We want them in the Sprint Planning Meeting, agreeing with what the Team takes in and, at the Sprint Review, giving us feedback.  Because these independent input and output checks are so vital, we must use their time efficiently.

Thus, for me it is better to think of higher level release plan refactoring and lower level release plan refactoring. And when people say 'product backlog grooming' they often mean lower level release plan refactoring of those stories about to go into the next sprint.

Again, the key idea here is that we ALWAYS refactor the release plan every sprint.  We improve it.  This is absolutely key to adaptive planning.

Release Planning: Completing the Plan

As discussed in the previous post on Release Planning, the user stories are now ordered.

(Please see this post for a list of all the posts on Release Planning.)

Now we must complete the Release Plan.

So, we must make the trade-off between scope and date.

There are three ways to do this:

1. Fixed Release Date.  We will release every X months or Y sprints.

Some teams or firms prefer to have a fixed release date. It makes things simple.  It makes managers and others realize that we will release.  They only question is exactly what will be in the release.

2. Fixed scope.  We will release when all of the scope (all the stories or PBIs in that scope) is/are done.

3. Trade-off.  We understand our velocity and go down the Product Backlog a ways. And ask: two sprints, umm, how many features are done?  Ok, three sprints, how many features are done.  Ok, four sprints, umm, customers would really like to see another release, the market needs it, but do we have enough?  Ok, five sprints, umm, I think we have enough.  Let's shoot for that.  -- It is that kind of trade-off.

This requires that we know our velocity.

Estimating Velocity

With an existing team, you might already know their velocity. With a new team, you must guess.

So, we do a calculation to get an educated guess.

First, for the 1 story point reference story (for effort)... how many ideal person days would it take. The Team huddles around the story and reaches a decision.  Imagine the number is 1 SP = 1.5 ideal days.

Imagine the Team has 6 doers (of real work).

Imagine the Team will do 2 week Sprints.

Let's assume the focus factor is 60%. That means, out of an 8 hour day, roughly 60% of the minutes are usable for the project.  The other minutes are used talking about the game, taking breaks, eating lunch, getting interrupted, answering questions, reading the email, going to company meetings, etc, etc.  Maybe some work, but not work on this project.

Calculation:

2 weeks = 10 days.

6 x 10 = 60

60 x 60% = 36

36 x (1-40%) = 21.6

21.6 / 1.5 = 14.4 Story Points for the 1st Sprint.

----

We subtract the 40% has a start-up "cost" for the 1st Sprint.  The Team is learning Scrum, the Team is "forming, storming, norming, performing..", the Team always wants to over-estimate what they can do in a timebox. 
For the 2nd Sprint, we subtract 20%.  For the 3rd Sprint, we subtract maybe nothing.

You may find that these rule of thumb numbers need to be adjusted for special situations.  But they seem to work for most start-up teams.

---

36 x (1 - 20%) = 28.8

28.8 / 1.5 = 19.2 story points for 2nd sprint

---

36 * (1) = 36

36 / 1.5 = 24 story points for 3rd sprint

And so on...

Communications Plan

I tend to put pressure on new Product Owners to release earlier.  They are mentally too tied to the concept of the 100% - 100% rule.  That nothing can be released until everything is done.  This is almost always just wrong.  Hence, I always ask for an earlier release.

Once the PO and Team agree on the scope and date, we then have to talk about the "communications plan", as I call it.

If the Team works with a manager who truly understands adaptive planning (meaning that the current plan will be revised and improved every sprint... this is only the first guess at the plan)... then tell that manager the truth.  Here's what we guess, this is what we are worried about.  This is our feeling about how it is likely to change.  And maybe we have contradictory feelings.

But often some key managers do NOT understand adaptive planning. These "tough" managers (or customers) want you to give a fixed date, and then deliver to that date.

Then you are stuck. So, we have to do what we used to do in waterfall. Add some "buffers" (aka padding, etc, etc) to the date.  For "problems", for new stories to be identified later, etc, etc.

It is hard to guess how much buffer to add.  We have no additional magic.

But, we do strongly suggest that you protect yourself and your Team. Do not get them in a situation of a Death March, trying to meet an impossible date.  More about this later....

And then we talk about, "ok, how will we communicate the date?"  (Almost always, the key issue is the date.) You have to start setting expectations that the date will change if other things change (substantially), and they are likely to change substantially.  This is not one conversation by the PO, but a series of conversations by and with many people.  It is over time that the start to see and feel the power of adaptive planning.

For some of you, the issue is not so much "communications plan", but "what do we put in the contract".  Too big a subject for this post.

Finalizing the Plan

Assuming you have "business stakeholders" as I described them earlier, then always you have to review the release plan you have with them.  Get their buy-in or comments or adjustments.  This of course may affect the communications plan.

So, this is most of the basics.  A bunch of issues we have not addressed.  Some I will address in the next post.

Self-organization

We have this idea in Agile, that the Team should self-organize.  This is an important idea. And also an important occurrence (eg, the reality precedes the idea).

In Agile, self-organization is compared to command-and-control.

We think self-org is an important thing to study, both in general and in your Team.

Why

Well, one, because it is just right.  People are free, and self-organization is saying that the Team is allowed to be free.

I guess this needs to be explained a bit.  Some will say: well, the company has bought their time as employees, so the company gets to define what the Team does.  Well, let is concede this at a high level; let us say that the company may define the vision or the goal or the general product.  Perhaps even the user stories.  The Team members are not slaves, but we can assume that, as employees, they agree to do the company's work for pay.  A contract.

But, devising the work, figuring out how they will get to the goal, they should have the freedom to do.

The second main answer is: self-organizing humans tend to do better work than human 'slaves' (humans directed by one or a few command-and-control people).

There is lots of evidence of this. The first book I recommend is The Wisdom of Teams by Katzenbach and Smith.  This is a rather old book.  But the basic evidence is that a self-organizing team out-performs, almost always, an individual.  And to such a degree that the extra cost is well worth it.  But, you must given them some degree of 'freedom'.

There are also a lot of more recent evidence.

Some topic you may wish to research:
Self-organization
Complex Adaptive Systems
Maneuver Warfare
Free Enterprise
Knowledge Creation

Note: Some people say that a free enterprise system is mainly characterized by (mostly) private ownership of capital (means of production). And attribute its successes or failures to that. Others focus on the freedom of individuals to make their own decisions (much like the "wisdom of crowds" idea) and on the view of the national economy as a complex adaptive system, trying to accomplish high-level economic success via many individual agents (people or companies) making their own decisions.  In our view, successful free enterprise countries exhibit many of the successful characteristics related to self-organization.

Command-and-Control Managers

Lots of managers have been taught, explicitly or implicitly, that the 'workers' are dumb, and the manager must tell the worker how to work.  In our view, especially for virtually 100% of knowledge workers (our domain), this is very very incorrect teaching.  But it is nonetheless, what they have been taught.

Now, some of them also understand freedom to some degree, and understand that they want the people in their group to 'think for themselves'. But, we can say with relative assurance, most companies have a lot of people who are relatively command-and-control in their style.

And, in pressure situations (our common situation), they want to use too much command-and-control.

Again, this is not true of all managers, but of many. It depends, in part, on the company's culture.

It is hard to convince these people to be patient for self-organization.

Teams that won't self-organize

This is seen in real teams.

There seem to be several root causes. One, the team has been beat down by command-and-control managers so much, that they have 'forgotten' how to self-organize.  Another: that they Team does not believe it when managers say 'self-organize'.  Another: The Team is fearful that by self-organizing they will be 'held accountable' with punishment a likely outcome.  To avoid pain, they refuse to self-organize.

Whatever the reason, two things can be said.

Many Team (perhaps with Agile coaches) do eventually break out from being 'stuck' (not self-organizing).

And some Teams may take a very long time or perhaps never do it.

The key advice is this: If the Team will not self-organize, or seems to want to self-organize to mediocrity, then a good manager should intervene.  Temporarily.

Perhaps prior key advice: Be patient. Often Teams will self-organize in two or three sprints.  Keep talking about it, and ask them if they need help.

Third advice: In the view of some (including me), some Teams lack some key skills to self-organize. For example, a new junior Team may not know really how to break down work into tasks for the sprint planning meeting. Sometimes 'holding their hand' as they mature is a very successful approach.  And 3 or 4 sprint later, they can be very good at self-organizing their own Sprint Backlog.

Learning to decide as a Team

I think each Team learns how to decide.

The first, most useful thing, is that everyone in the Team gets to offer input on a decision.

Next, the Team needs to accept that no decision is ever perfect.  Thus, decisions in general must be made, perhaps not always quickly, but promptly.

The Team needs to understand the impact of decisions on the morale of the Team and on the success of the Team.

In our view, most teams go through a forming and storming period of decision-making.  And then later get better.

Good self-organization... and better

Lots of Teams seems to self-organize well.

What is also common is for most Teams to plateau.

In part, we may say that a root cause is that most Teams want to reach a stasis... a place where things are balanced and where change slows down.

But have they reached the height of improvement?  We think not.  Some Teams have reached much higher heights.  And some Teams keep on improving.

There seem to be two main factors (or sets of factors):
* magic -- or, more accurately, a bunch of things that are hard to describe.
* a bunch of factors that people talk about, and some teams study and work on

Some of these last factors seem to be quite 'soft'.  Love, listening, creativity, heart seem to be among them.

Lastly

If you have never been on a good team, it is hard to understand what self-organizing is all about.

Within the Team, it might be rather rough and ready. But a lot depends on the specific individuals in the Team.

Release Planning: Risks, Dependencies, Learning, MMFS and Other

Now we come to the point of (re)ordering the Product Backlog.

(This is a continuation of a series on Release Planning that starts here.)

You will recall that the Product Owner's main goal is to maximize the Business Value from the Team.  In some time period (shorter or longer, as makes best business sense in your specific situation).  So, in theory the R factor (see the previous post) should be the way to organize the Product Backlog, ceretis paribus (other things equal).

But of course other things are never exactly equal.

So, here is where the most uncommon thing comes into play.  Common sense.

And we re-order the work based on these factors: Risks, dependencies, learning, MMFS, and other factors.

We recommend that anyone in the Team can propose to move a user story earlier or later based on these factors. But he or she must discuss the change with the Team and get reasonable consensus.  If there is no consensus, then the Product Owner gets the final decision.

So, let's discuss each factor in turn.

Risks. There are potentially many types of risk. Business risk is often a big one. For example, we need to get a feature out before a competitor.  Or we have a weak understanding of the specific detailed features needed in area X.  Technology risk is another common factor. We are about to use new technology, and we are not sure how it will work.  And there are other types of risk.  In Scrum, we tend to want to attack risk early, by doing one or more stories in that area, to see if the risk is just a worry, or a real roadblock.

Dependencies.  Again, these can be of several types.  In the past, we often organized the work mainly by technical dependencies.  Since the job now is to maximize business value, we sometimes must sacrifice efficiency of the Team.  But if technical dependencies will destroy the efficiency of the Team, then we must deal with that. (Ok, seriously diminish the efficiency...).  And there can be business dependencies as well.  It makes more sense to develop step 1 in a process before step 2.  At least sometimes.

Learning. In Agile we recognize the importance of learning. We need to learn what the customers really want. We need to learn some technical things to become more effective.  These can be good reasons to chnage the order of the work.

MMFS.  Minimum market feature set.  This phrase is from Software By Numbers by Mark Denne and Jane Cleland-Huang.  The idea is that there is some minimal set of features that must be put together before a customer can realize the value of the whole set.  Sometimes this minimum is quite small, quite small indeed.  In other circumstances it is much larger.  In general, too many of us (producers and customers) have been brainwashed into believing the 100%-100% rule, so that we think the MMFS is much larger than it really is.  In any case, low value features sometimes must be moved up, in order to add the 'missing something' to make the next release truly 'usable'.

Other. This is a catch-all for all the other reasons we have to change the order of the user stories.  My favorite example is this: A committee is going to me in 3 weeks to decide on the funding for our project.  George is on the committee.  In our opinion as PO and in the opinion of everyone else, George is much too excited about user story 87, which currently would not be built until the third release, and that is assuming no new user stories get identified, which is very very unlikely.  But, George is on the committee. And user story 87 is only 5 story points (our velocity is 25).  So, we ask the Team to go ahead and get the story done in the next Sprint so that George helps assure that the project gets further funding.  Not rational, not 'the right thing to do', but sometimes you have to deal with real people and irrational things have to happen.

In our experience, Risks and Learning should be used more often to re-order the product backlog.  And Dependencies less often.  But in any case, using the R factor solely is almost never the right answer.

How to do this

We recommend that the product backlog already be ordered by the R factor. (The R factor was discussed in the previous post on Release Planning.)

We recommend that the whole Team be there (PO, SM and implementers) and the business stakeholders.

Then, anyone in the group can start to suggest re-ordering the product backlog based on any of the ideas above.  Any move has to be explained to the whole group.  If there are disagreements, the PO makes the final decision. 

Again, let me emphasize that sharing knowledge with the whole team is at least as important as any other outcome we are trying to achieve.  So, doing this without the Team is not recommended.

Normally this does not take very long. Again, 6 months of work for one team is typically expressed as about 50 user stories.  So, re-ordering 50 user stories, where most do not move, does not take long.

More to come....

Agile Specification

This is a "just enough, just in time" concept.

Please read these blog posts:
http://scrum.jeffsutherland.com/2009/11/enabling-specifications-key-to-building.html 
http://scrum.jeffsutherland.com/2008/09/agile-spefiction-is-it-hoaz-or.html

OK.  So, it is something 'written' that the PO gets done for the Implementers in the team. The Implementers define exactly what they need, and the agile spec is neither more nor less than what they need.  To get it done right. Quickly. High quality. Etc.

What might it contain?

Well, anything useful.

I think it is easiest to think of conceptually if you think of 1/2 page (or 1 page or maybe 2-3 pages if the drawings are big) tied to each small sprint-sized user story.

It is simplest to think of the Agile Spec being 'written' 'one sprint ahead'.  And being checked for 'ready, ready' before the Sprint Planning Meeting.  But your real world may require some common sense adjustments to that. But be careful; common sense is remarkably uncommon.

Maybe hand-written, maybe on a wiki.  Maybe in a Word doc.

Who writes it?  Well, the best people, of course (self-organize!).

It might hold:

• the acceptance criteria
• a business flow
• a list of business rules
• a wire frame(s)
• a mock-up of the screen (if that means something different to you)
• a simple use case kind of flow (not all the darn UML use case stuff... just something, just enough) (to me, this is a variation on a business flow, using a few specific symbols)
• a data flow
• new data elements (or whatever you guys call them)
• key data elements and key values in this context
• a screen flow
• a simple design picture
• a data flow, maybe simplified
• an example (eg, if X, Y, Z inputs, then we expect A, B, C outputs)
• anything else they may find useful to build it quickly and for it to EXCITE the customer

Any one Agile Spec will NOT have all of these things.

It does not repeat the usual BS that we used to put in specs. That no one really read.

It does not say all the stuff they know well already.  It is not trying to be 'comprehensive'.

We are _not_ managing through documentation. Consider this sentence repeated 15 times, 15 different ways.

We are sharing knowledge in one effective way. It is not the only way to share knowledge, and create knowledge. Two people at a white board is still going to be used. A lot.

And we definitely use the Agile Spec as a basis for conversation, to confirm that everyone is seeing the same elephant (well, in this case, the same small sprint-sized user story).

For some people, who maybe had too much fun in college, we need to write or draw more.

For some people, who maybe took their Ginkgo today, we need to write or draw less.

Any questions?

Ozymandias: Creation birth pangs

It is hard sometimes to create. We wonder, will our darlings ever survive.  I have spoken already of a book called The Courage to Create by Rollo May.

Now I want to show a short poem by Shelley.  Ozymandias, it is called.

I met a traveller from an antique land
Who said: Two vast and trunkless legs of stone
Stand in the desart. Near them, on the sand,
Half sunk, a shattered visage lies, whose frown,
And wrinkled lip, and sneer of cold command,
Tell that its sculptor well those passions read
Which yet survive, stamped on these lifeless things,
The hand that mocked them and the heart that fed:
And on the pedestal these words appear:
"My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!"
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.

Ozymandias was once a famous king, of surpassing wealth and power in his time. And Shelley wrote this after seeing the ruins of his kingdom.  You will note that Shelley, the great poet, was not daunted by this vision of despair.

I note with irony and pun-ishness, that in our computer world, the lone and level sands stretch far away.  (Ok, Virginia, I am alluding to how sand becomes silicon, as in Silicon Valley. The valley of dreams.)

I hope that you do not seek that fickle goddess, Power.  Or wealth (perhaps slightly less fickle, if you know a good Swiss banker).

But if we only build castles of dreams in the breasts of our friends, even those dreams, once built, can die surprisingly quickly.  A new product will come along and charm them a different way.  I am sure any of you can think quickly of an example.

We must have the courage to create, and the laughter to let that beautiful creation come crashing down. And then to create again.

I will close with this quote from Henry Ford:

I cannot discover that anyone knows enough to say definitely what is and what is not possible.

Release Planning: Effort (2)

Now we come to the point of describing Planning Poker.

(This is a continuation of a series on Release Planning that starts here.)

Planning Poker has been described before, so we will be brief.  It is described at greater length many other places.

***
Some basic characteristics:

• We find the 5 best experts on effort for this work.  (About 5; maybe 3-7.)  In almost all cases, this means the team of pigs.
• Usually the Business Stakeholders (as I call them) will not stay around for this work.  This is ok. Not ideal, but ok.  We will bring them back in later.
• We use the planning poker cards with the Fibonacci scale.
• The approach is wide-band delphi.  Delphi means we use the best experts we can find. Wide-band means that we allow the experts to talk and learn from each other.  This bears strong resemblance to the knowledge creation ideas from Takeuchi and Nonaka.

The basic technique

We have about 5 Experts.

We use (solely, mainly) the people in the team who will be building the product.  The affects motivation.  This affects their knowledge.  This will affect their later behavior. We try hard to get all of them, so that none of them feels left out.

The Product Owner is typically not one of the voters, but he/she is there. The PO has to make sure that the team is understanding each story correctly.  Typically the PO is a business person and in any case is representing the Firm and the Customers.  So, when those kinds of questions come up, he must be there to give them the best possible assumptions to work with.

The ScrumMaster (SM) is there to facilitate the meeting or the work.  Ex: To try to get the quiet ones to talk more and the talkative ones to talk less.

In this discussion, we will assume all the PBIs (Product Backlog Items) are in the User Story format, so we will call them stories.

The Experts must now choose the reference story.

Imagine that the team has 50 stories in the Product Backlog, covering about 6 months worth of work.  The Experts choose from that set the smallest story.  Well, except that it should not be too small. Ideally it is about 1 ideal person day (after adding together all the ideal hours from all the required skill sets).  [Someone should check that the story is about the right size. But don't tell anyone, and especially don't let the experts start thinking in units of time (days, hours).  Still, if the story is too big or too small, it starts to distort the voting, in my experience.]

The reference story is arbitrarily given a 1. Meaning, it has an effort value of 1 Story Point.

Note: For those who are just reading this post, an earlier post talked about how the Team must have a strong DOD (definition of done). The DOD should make clear what things are being done in the Sprint to get the story 'done, done' as we often say.  So, it is the effort of 'these things' done during the Spring that we are estimating.  Earlier we talked about a minimal DOD.

OK, now the team estimates the relative size of all the other stories in comparison to this reference story.  This happens in this way:

1. Select the (next) highest value story.
2. Discuss it briefly to assure everyone understands it the same way. PO describes story. Experts ask him questions.
3. Someone asks "any more questions?"  If no....
4. Each Expert privately selects a Planning Poker card that best represents his feeling of how much bigger the new story is in comparison to the reference story. For example, if 7 times bigger, the choice is between a 5 card or an 8 card.  Likely, the 8 card will be chosen...
5. If all Experts are within 3 consecutive cards of each other (ex: all have either a 5, 8 or 13), then average the numbers. Example: 5, 5, 5, 8, 13 .... averages to 7. The average is rounded to the nearest integer.
6. If the Experts' votes are more dispersed (ex: 3, 5, 8, 13, 20), then the two extremes talk (mostly). In this example, the person with the 3 and the person with the 20 both talk about their assumptions, etc.  If the assumptions are business-related, then the PO can decide which assumption is correct.
7. With the new information, each Expert votes privately again.
8. Voting and discussing can go on a couple of rounds.  Almost always, the final answer for a card is the average after the Experts get within 3 consecutive cards of each other (Ex: votes are 2, 3, or 5).
9. If, after X number of rounds, the Experts have not reached some degree of consensus (with 3 cards), then the team should just take the average. Each team can decide how big X should be.  My guess is 4.
10. Once the number is decided, it is written on the card (story) in such a way that everyone knows that it represents the story points (color and placement on the card usually make that clear).

A few additional comments:

• The discussion is actually the most valuable thing.  The numbers drive a better conversation about the more important stuff.
• Sometimes important assumptions are identified. In that case, the assumption should probably be recorded (eg, on the back of the card?). Later, if we discover that the assumption is incorrect, we can refactor the story points for the related stories.
• Sometimes the Experts will want to address certain general issues.  The issues might be architecture or design related. This is where the SM has to use good judgment. Typically let them discuss for 'a while' but not too long. Maybe make one or two drawings.  Make and document a few assumptions, and then get back to Planning Poker.  Sometimes one or two people on the team want to discuss these issues too long. In this case, the SM must use good judgement and get the Experts back to Planning Poker.
• You will  hear of people suggesting that the Experts must agree on 1 Fibonacci number (eg, 8) for a given story.  This is _not_ recommended.  First, it gives a strong incentive for people to too quickly start to shade their numbers, rather than vote what they really think.  They find that George, the senior guy, is stubborn, and to avoid conflict and to keep things going, they decide, almost subconsciously, to start voting a closely to what George says as fast as they can.  The research shows that the average is more likely to be the correct estimate. And it actually takes less time to reach that number (if everyone is voting honestly).
• Usually one or two new stories are identified while we are doing planning poker. This is normal. Occasionally it turns out to be the most important story.

At the end

It usually takes no more than 1.5 hours to estimate 50 cards well.  The first few cards take longer. Then things speed up. On average; sometimes one or two later cards will take some time.

Once all the cards have been estimated (for effort), all the cards should be put on the wall. And then the whole Team should gather around. And see if they can identify one or two 'stupid' cards.

It is very common that 2 or 3 stories that were estimated early on will need to be re-estimated, in the team's opinion.  This is fine, good even.  And normal.  They now, as a team, are much smarter than when they started Planning Poker.

Cost-benefit analysis

Now one or two people in the team calculate the R ratio for each story.  BVP divided by SP.  For each story.  The R should not be more than one decimal place.  This gives:

• the low hanging fruit
• the bang for the buck
• the return on investment

...however you want to put it.

We next suggest that the PO organize the story cards based on the R number. Highest R first.  Lowest R last.

We ask them: What do you think?  Is this the right way to do the work?  Often they say: Well, it is a good start but we need to make some changes.  Which is 99% of the time, the right answer in my opinion.

What ideas do we use to re-order the work?  More on that in a post soon.

The importance of a real team

Scrum requires a real team.

The word 'team' is often used, often in different ways.  So, let us define it.

According to "The Discipline of Teams" by Katzenbach and Smith, this is what you should look for:

1. A meaningful common purpose that the Team has helped shape.

2. Specific performance goals that flow from the common purpose.

3. A mix of complementary skills. Including technical/functional, decision-making, and interpersonal.

4. A strong commitment to how the work is done.

5. Mutual accountability.

For more discussion, see The Discipline of Teams.

The team needs to be small (~7), stable, cross-functional, and self-organizing.  The team is in it together.  And should help each other.

In general it is best if the team is fully dedicated to one missson, one purpose, or at least the one team's goals.

All of these team characteristics together are key to starting Scrum.  Got to start with a real Team.

Note: Not everyone wants to be on a Team.  And for sure, not everyone walks into the office knowing how to act in a real Team.

Meet the Meeting Killers

Here is an entertaining article in the WSJ.  About people "types" that kill meetings.

Scrum of course has some meetings. It is trying to minimize meetings, and make meetings better.

But as soon as you have people and meetings, you can have some....umm...interesting times.  So, may your meetings not be interesting this way.