3 Methods to increase Business Value

Posted on October 13, 2012 by Joe Little

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):

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

Choosing a Scrum course/trainer

Posted on September 22, 2012 by Joe Little

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 (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 Implementor Role

Posted on August 27, 2012 by Joe Little

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

Posted on August 25, 2012 by Joe Little

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:

The PO is very important to success.
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.
Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
The PO is definitely a member of the Team. Given real life, often 100% of his time is not enough (see also #7 below).
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.)
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.
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.
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.
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.
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: If the PO comes to the Daily Scrum (usually), then over time it will make them at least a bit better.

Certainly some of you have done different things and been fairly successful. For example, with the PO not coming to the Daily Scrum. But could you have been more successful by having him come? 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 to 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.

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

Posted on June 29, 2012 by Joe Little

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.

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….

Why our CSM (Scrum) course + Workshop is unique.

Posted on May 14, 2012 by Joe Little

We believe our CSM (Scrum) course plus Workshop is unique. And better. For the following reasons.

1. We focus on results. We want you, your team and your customers to get real results. In a big way. In 3 words, more satisfaction, more money, more fun.

2. Therefore the teaching style is not toward remembering explicit knowledge. The teaching style is to enable you to change your own mind, so that you want to take action.

3. We focus more on ‘why’ each Scrum practice is done. We think that this ‘music’ makes the dance steps of Scrum more powerful, more effective.

4. We have learned from 8 co-trainings with Jeff Sutherland.

5. We are more business-oriented than most Scrum trainers. And still protective of the Team being asked to do a Death March and yet call it Scrum.

5. While we offer some serious challenges, and ask you to challenge yourselves and your company to truly achieve the results you deserve, we are also realistic. We appreciate that Scrum will be tough. We offer sympathy. But not too much.

6. Attendees say the Workshop converts the ideas of the course into action. So that the Team can get off to a good start.

Killing Babies or Sizzling Steak

Posted on May 12, 2012 by Joe Little

I thought I would share this story, with one or two key metaphors. Perhaps useful to you. I use them in classes quite a bit.

***
OK, the PO is trying to optimize on the Pareto idea (80-20, the vital few).

At the beginning of the project, the team looks at the release plan and says: “OMG, if we try to get all that done by Aug 15th, we’ll die!” So the PO, realizing that even more (new) work will be identified later, gathers the business stakeholders for a meeting.

“Guys [speaking to the business stakeholders], we have to cancel from the release the bottom 30% of the stories. We just won’t get them done, or at least can’t guarantee them by that date. And we know new stories will be identified by then. I need your agreement they won’t be in the Aug 15th release.”

They look at him in disbelief. And then the BSHs (business stakeholders) get upset.

“What the…! You haven’t even started work! I fought and fought with my team to exclude other stuff and I fought to get those babies in the Release. And now, before you even started, you want to kill my babies!”

Suffice to say, it is not a fun conversation and they don’t want to agree.

Now, I do think the PO should make them aware that getting all stories done will be a big challenge. And if the PO can show a true Pareto curve, it is a much better conversation. But don’t try to get them to agree at this point. Too much pain, too little gain.

***

Now, imagine later. You have built two Sprints of the top stuff. You serve it up very seductively in the demo. You can see the top BSH drooling.

You say: “George, do we have all the top stuff built for you?”

“Well, I need story 23 and 47 too. But yes, this stuff is all the top stuff. And it looks good. I mean, aside from those missing stories, it looks…give me a second to wipe my mouth…it looks r e a l good.”

“After the next sprint, when we complete some other stories and stories 23 and 47… George, how about we then serve you up some of this sizzling steak, fresh-off-the-grill? We give you a release then?”

“Well, how about the broccoli and the mashed potatoes and the creme brulee?”

“Yes, we can give you those later, in later releases. And how about we release you the sizzling steak _now_ (well, next sprint)?”

Now it becomes George, and not you, who gives the other BSHs the look… “guys, I think this is the best for the firm… I need you to TOFTT and let us do this release now… you’ll get your stuff real soon.”

And he looks at Mary (the 2nd BSH): “Mary, we already have a bunch of your stuff in there too. What do you think?”

Mary: “Well, it does not have everything our group needs, but, yes, I think we could make use of what’ll be there by the next Sprint. Are we really gonna get the later releases?”

Geo: “I think so. Heck, they never had this much working software before by this time. I think we can trust those SOBs now. Sorry, Mr PO, I meant SOB in the nice-est way.”

Mary: “OK. How about the rest of you guys?” ….

***

So, you can see that it is a totally different conversation. But with the same effect. That we execute and release more on the Pareto idea than on the 100% – 100% rule (where we often die in the death march).

And all because we served up the sizzling steak seductively. We did not win on logic, but on the emotion of the drool.

Now, serving it up seductively is a fine art. Seduction. Well, there is Joe the geeky PO and then there is Casanova or Mata Hari. (Ok, yes, an exaggerated comparison…) Do I need to ask which one is going to serve up the sizzling steak more seductively? Thought not.

Now, one of the key benefits of the ‘sizzling steak’ technique is that the Team now has a better life (no death march, seen to be victors). Which means they are more creative. Which means everything should be better.

***
The story and the metaphors work for me. YMMV.
It does help if the key person is not a vegetarian. And even likes steak.

Later, they will say “Oh, yeah, I liked the story about the sizzling babies.” And then they will laugh. But they might remember it longer.

Release Planning: Product Roadmap

Posted on May 9, 2012 by Joe Little

I did a session today at the Atlanta Scrum Gathering about ‘Joe’s Approach to Release Planning’. Jason Tanner asked “what about the product roadmap?” And his question made me realize that I have not said enough about that.

My quick thoughts.

1. You need a product roadmap. For almost all products. Well, at least almost all the products I have worked with over 20+ years. I suppose I am not an expert on iPhone Apps, for example. Maybe they are an exception.

2. What time span should the product roadmap cover? Yikes. This is hard question with no perfect answer. Longer than the implementers want to think about and shorter than the ‘planner’ type wants. OK. For most products, about 1 year. For fast changing, fast delivery products, less than one year, maybe even only 3 months (assuming say monthly releases). For ‘big’ products, you might need multiple years.

3. The purpose of the product roadmap is not to be right. But to generate useful thinking about ‘longer term stuff’, and provide some context for shorter-term thinking.

4. YAGNI. First, You Ain’t Gonna Need It has proven to be a pretty good principle. Stuff happens, and all the knowledge created to go down path A is now useless. This principle always tilts things towards less investment in longer term planning. But of course, this principle is not the whole story.

5. Purpose: Human beings seem to be more motivated, seem to enjoy life more if they feel there is a purpose to their lives. And a product roadmap is an example of something that can and should be used to put things in the context of purpose.

6. Identify hard-to-reverse decisions. Many decisions or actions are easy to reverse. Some are quite hard. The harder a decision is to reverse, the more costly, the more it is worth some time to think about it and decide with a higher chance of being right. A product roadmap can help us identify those kinds of decisions, and put them in a context. For example, help us understand when those decisions must be made. What I am saying here is very similar to the Poppendiecks’ ‘decide at the last responsible moment’ concept.

7. Practical. For a team just starting Scrum with a fairly normal product, if the group seems ok with it, I like to plan about 6 months worth of work (typically one or two releases, at least as initially conceived). And stop there for now. And start Sprinting. And then later build out the rest of the product roadmap.

Why? Because they don’t really understand the power of agile and agile adaptive planning until they do Sprints. And until they do the Release Plan Refactoring. It’s a think-do feedback loop. They need to experience it sooner. Then, having that tacit understanding, they start to plan better with less BS. And with more purpose.

***
Comments?

Taking Ideas on a Test Drive

Posted on May 7, 2012 by Joe Little

I am a strong proponent of “show me the money.”

In other words, there are lots and lots of ideas that sound good. And only a relative few that are really worthwhile. And we only know by trying to put the idea into action.

But even this basic scientific idea is not complete. I would agree that not all ideas are subject to proof in a scientific way. Even though scientifically it might be proven that murder were ‘correct’, morally I still am going to think true murder is wrong. (No, Virginia, we are not going to have a debate on all the possible situation and moral permutations of killing a person.)

Here is a WSJ article about a new book, Uncontrolled by Jim Manzi. Haven’t bough the book yet, but the article makes it sound interesting.

And this is what lean-agile-scrum does. We try to do a series of small semi-controlled experiments. To see if we are really on the right course.

If you have a problem reaching the WSJ article, contact me and perhaps I can send it to you.

A list summarizing Scrum

Posted on May 6, 2012 by Joe Little

Revised May 6, 2012.

***
The list below is not self-explanatory, but it covers the key ideas one has to know and execute on to do Scrum professionally. Of course, becoming proficient at doing them at the highest level (at the rugby World Cup level) is a lifetime’s work. Rugby is a simple game with simple rules, but to reach the highest level of play is very difficult.

This list could be used as a starting point for defining ‘agile’ or ‘scrum’ in your firm. I am suggesting such a definition could drive useful conversations. And it fits on one page (a key criterion).

A list that summarizes what Scrum is:

Roles:
Product Owner
ScrumMaster
Implementor (‘Dev Team’ role)

Events:
Sprint – 4 weeks or less.
Sprint Planning Meeting
Daily Scrum
Sprint Review
Sprint Retrospective

Scrum Artifacts:
Product Backlog
Product Backlog Items
Sprint Backlog
Working Product
Increment (of working product)
[Sprint Burndown chart]
[Release Burndown chart]
Definition of Done
[Public Impediment List]

Key Ideas:
Scrum is a process framework
Deliver business value faster
The Product Owner is maximizing the value delivered by the Team
Inspect & Adapt
Transparency
Self-organizing
7 plus/minus 2
Build iteratively and incrementally
Working product at the end of each Sprint
Potentially shippable product increment
Need for feedback
Always learning
Always adapting to good and bad change
Usefulness of high quality
Scrum hates technical debt
Knowing work remaining in a Sprint (daily)
Knowing work remaining in a Release (every Sprint)
Protecting the implementers from disruptions
Protecting the implementers from the Death March
The ScrumMaster drives the removal of impediments
Must add other practices (e.g., engineering practices) to Scrum to do work
Scrum does not include agile release planning (but you probably need it)
Scrum is consistent with the Agile Manifesto and Agile Principles
The Team should be having more fun (and be more creative)
Sprint Planning Meeting, parts 1 & 2.
The Product Owner orders the work in the PB; the implementers decide how much they can do in a Sprint.
Sprint Goal
Sprint “commitment”
The 3 Daily Scrum questions
Purpose of Daily Scrum: self-management
Demo working product & get feedback
Servant leadership
Chickens can help
Just-enough, just-in-time, documentation

***

Your comments please.

Here is the file: http://agileconsortium.pbworks.com/w/page/53405031/List%20summarizing%20Scrum