Wide-Band Delphi Estimation for Business Value - 3

This is the third in a series of three.  See part 1 and part 2. ***

How can we use the BV points

We could organize the Product backlog strictly by BVPs, at least initially.

In fact, I recommended this, to see patterns or to make any mistakes obvious.

But I do not recommend doing the work in the order of the BVPs, the story with the most BVPs first.  This is much too simplistic.

The key thing we are missing is cost.  For centuries now, man has talked about the trade-off between costs and benefits.  And in business we have the concept of return on investment.  You invest $1000 (the cost) and get $2000 back (the benefit).

Can we use that concept here?  Yes!

For each story, we can calculate an R factor by dividing the BVPs by the SPs.  This gives us a rough ROI for each story. We could call it CBA (cost benefit analysis, or bang for the buck).

We think this is useful.

By no means does the R factor completely determine the order of the Product Backlog, but one can readily see that following the R Factor could help us maximize the business value per release, other things equal. (Of course, other things are not always equal, but we will not try to address that here, except to say that the Product Owner or others must re-order the Product Backlog some to account for the other things.)

What is the value of a BV Point

Sooner or later someone will ask: What is a BV Point worth?

At first, it is relative, strictly relative.  That is Story X is 50 BVPs, which means it has half the value of the reference story (which has 100 BVPs).

But let's imagine a very simple situation and see what it shows us.

Imagine a product backlog.

Imagine it has a total of 1,000 BVPs across all the stories.

Imagine that we know that the total Product Backlog is worth $2,ooo,ooo.

In that case, we can calculate that each BVP on average is worth $2,000.

You can't cash in your Story cards at the bank for money (based on the BVPs on each one).  You must release and there are MVP or MMFS issues as well, but one can at least feel (fairly accurately) that the BVPs are not just fantasy, but actually a foretelling of a future reality.  Well, if the customer still wants it when we deliver, and if we had good BV estimators.  

Objectivity and Visibility

In our opinion, whatever business value is, it is ultimately in the mind of the customer, and in the future.

So, to us as business people trying to solve a business problem (help people and also not go bankrupt), this seems altogether too subjective.

The BVPs start to make it a more tangible thing.  And this helps.

Whatever number we decide ob is then no longer a 'feeling' inside us (or one of us), but rather a number 'out there' on the story card.

This helps.

It helps in many ways, but let's give one example.

In former days, we would ask two experts for Story X: Is it high, medium or low?  And of course they would both typically say high.  Now, we ask the two experts to vote with cards. One says 21 and the other 89.  We and they can quickly see that one high is not another high.  And they can start to have the famous conversation about how high is high.  We can laugh, but actually this is a useful conversation.

In fact, one of the most valuable things about the numbers is that it makes the conversations better.

Tacit Knowledge

We just gave the example of the more useful conversation that arises.

When they vote, and they disagree significantly (wider than 3 Fibonacci cards), we want the two extremes to talk. Others may talk as well.

What do they talk about? Well, we think it is best to think of this as sharing the Tacit Knowledge.

One definition of tacit knowledge is "all that stuff we know, but we don't even know we know it, and it has not been made explicit it."  And, obviously, this is knowledge that we think is relevant and even useful in a given domain, or to accomplish a given set of work.  Explicit knowledge is knowledge that has been written down or put in a formula.

Do you want a Team to share their tacit knowledge?  Of course! In all the relevant domains.

Is it easy to get them to do so?  NO!  It is extremely hard.  In part because they don't know what they know, and in part because each person doesn't know what the other people are missing.

Priority poker forces them, in a fun way, to share the tacit knowledge.

In my opinion, this is the most valuable thing about the whole exercise.  Not that other things would not justify it.  But the sharing of the tacit knowledge is the single most useful thing.

Helping the Product Owner

Priority poker makes the PO job easier.  And it is a very very hard job, so any help is welcome.

In what way? Without priority poker, the PO had to make tough choices in ordering the Product Backlog.

Let's assume, in former days, that he talked to all the business stakeholder individually.  And they disagreed, of course, on the values of different stories.

So, the PO has to use up his political capital in just saying: This story is #1, this one #2, etc, etc.

This was 'risky' and often there would be some tense conversations. Too often the PO would be wrongly overridden by one or two business stakeholders.

Now, with the priority poker, all the business stakeholder educate each other. (Again I say, bring the popcorn.  This is fun to watch.)

Still sometimes, in relatively rare cases, all 4 of the business stakeholders are being stupid at the same time, and the PO's number will make only a small difference in the average.  And let us assume the PO's number is right.  Only then does the PO have to use political capital to 'move' the story to a more correct BV number or more correct ordering.

This reduction in effort frees the PO to focus his work in other areas.

Overall benefits

I want to reiterate the key overall benefits I mentioned earlier.

• They all see the same elephant (better)
• They all are more motivated
• They all have shared the tacit knowledge

If priority poker is done with the implementers, these benefits accrue to the whole team.  And remember that motivation is not just a 'feel good' thing; higher motivation directly leads to higher productivity from the Team.

I hope you try priority poker soon.  And tell us how it went.  I hope you will tell us how much it helped you.  

Agile Contracts

Jeff Sutherland did a presentation at Agile 2013 that I think everyone should read and think about.  And read and think about again.

Here is the slide deck:

http://jeffsutherland.com/Agile2008MoneyforNothing.pdf

Deliver Faster

Why do we want to deliver fast, and then faster?

Well, the first reason is...that's what the customer wants. The customer is thirsty. They want a drink now. She does not want to wait for 3 months to get a major delivery of 200 water bottles. A drink now, please.

The second reason: time to market.  In this context, I mean we need a good poduct to market before the opportunity goes away.  Before the competition beats us there, or before the most important problem has changed.

Third.  More and more my clients are having re-organizations rather frequently, so someone in an Agile class quipped "we need to deliver faster than the next re-org". This meant within the next 3 months.

So, yet another reason to deliver fast. If managers change, then you can deliver what the outgoing manager wanted (with a bit of luck), and then start marching forward with what the new manager wants.

But there is more. We need to deliver faster because we get more feedback.  In this way, we have a smaller release, but learn more quickly whether it is on target or not. And, taking that feedback, we can modify the next release. Or perhaps have no more releases at all.

This minimizes risk. This minimizes WIP, whose value...if we wait long enough...will always eventually go to zero.  So, we have minimized the potential loss in value of the WIP, the work-in-progress.  We have reduced the risk.

All the reasons that make us want to deliver something faster.

Yes, it must be a minimum marketable feature set.  But we are learning that 'minimum' is smaller than we thought.

Deliver faster.  This is our goal as a Team. It is not a goal that the managers stupidly foisted upon us. It is a real need in business.

Then the question becomes: how do we do that?

Advice from an experienced successful PO

I was doing a course with Dave Muldoon in Ottawa. And Rich O’Grady visited us.

He had become a very successful product owner in a difficult environment where others had failed (not done well enough).  He mentioned 6 ‘top tips’ on that day, and then he wrote me explaining them a bit more.  What he wrote was pretty much what he said that day.

Here is what he wrote (I added some numbers):

 

1, Transparency

- When I took over there were several teams. Some had backlogs and some claimed to have backlogs. The ones that had “backlogs” were usually owned by the manager, updated by the manager and only viewable by the manager.

- I ran a workshop to create a new backlog for the whole organisation (~40 persons) and it was placed on a wall initially. We had to put it into a tool (JIRA) due to the fact I work on a different continent.

- Everything is on my backlog including defects.

- My backlog is viewable by anyone in the entire company but only I can change an item’s priority.

- This simple exercise in transparency allowed everyone to see what we would be working on and to simply build trust.

 

2. Only my Product Backlog

- Another part of the above exercise was to give a very clear message. The team members can only work from my backlog. If they work on anything else they are wasting my money.

- I forced a couple of teams to stop what they were doing by having executive approval to stop their work. I them told them to look at my backlog and consider what they could do from the top. At this point half the teams actually self reorganized as the team make ups at that point could not fullfil my backlog.

- I encourage team members to generate ideas on how we can improve what we do or how we do it (actually wrt ‘how we work’ – I always listen to them first). However, I want to hear about these ideas when they are at the whiteboard stage.

Continuous Value Analysis

- I built and used a simple and quick spreadsheet.

- I educated my stakeholders about the illusion of accuracy.

- My stakeholders enjoyed being shown at an EPIC level the different relative value points (I can’t easily attach dollars to what I do so I simply used a weighting system across a broad range of categories).

- My stakeholders are now in the routine of a quarterly review where they get to see at an EPIC level progress and if we are still getting value.

- With my teams I do this on a sprint basis. Some times it’s subjective other times there are very clear objective measurements. On a sprint basis I continually prioritize the backlog looking to keep the most valueable at the top.

3. Not the Manager

- I am not the manager (of the people in the Team). I am the Product Owner.

- As a coach to other POs, I noticed this recurring time and time again. The PO would simply be too involved in the team and dealing with issues the team should be dealing with.

- A number of POs were ex-managers so perhaps they were still trying to work as a manager?

 

4. Feedback/DOD (Def of Done)

- Always good!

- Don’t be afraid to say something is not done (0 points and back to the backlog).

- It’s a clear message.

- Essential here is a clear and collaboratively formed DOD and good acceptance criteria.

- POs make mistakes too (we’re all human) and shouldn’t be too proud to admit they got it wrong as well (nice short sprints or attendance to some standups would help).

5. I had a vision

- I had a vision formed by listening with my teams, users and stakeholders.

- It is clear and concise.

- From here “we” formed nice clear objectives (written in the conextra story format).

- Every item of work on my backlog can be linked to one of those objectives.

- It allows us to see the connection from top to bottom as to WHY we do what we are doing (and not doing).

6. Small Items

- I didn’t actually talk about this one but I wish I had.

- Small to me is about 1 week of work for the whole team.

[Ed. Note: The firm was used to 'features' that we often 6 months of work for 1 team. So, these stories are much much smaller.]

- It takes a lot of work to keep the backlog manageable when everyone is trying to add so many tiny tasks on to the backlog.

- Several times I have ‘collapsed’ PBIs else the backlog gets unmanageable very quickly.
- Also I have several teams so I can manage about 20-30 items per sprint but not 70.

 

***

 

Thanks Rich!

At first, when Scrum and when Waterfall?

When your company is first starting Scrum, how do you decide which projects use Scrum and which ones do it 'the old way'?  (Let's assume the old way is a form of waterfall.)

Here are some factors that might tilt a project toward Scrum.

1. Is the Team willing to try Scrum?  The more positive they are toward Scrum, the better.  At first it will be new, bumpy. And you want a Team willing to work through the bumps to get to some success.

In part, you need a little success in your company to get the more skeptical types to feel comfortable using Scrum.

If the Team starts in a skeptical a mood about Scrum, they start to make it fail.

2. Will someone help with the Impediments?  The more this is positive, the more you choose this work.

3. Good product owner.  If for one project you can get a good PO available 80%, and for another the PO is weaker and available 40% -- choose #1.

4. Reasonable stability of work in the Scrum.  If project 1 will not want to change the work during the Sprint much, and project 2 needs the work more often to change in the Sprint, then choose 1.  But this is reason #4.

You want the Team to commit to work in Sprint Planning Meeting, and start to see the positive momentum of completing it by the end of the Sprint.  Fewer changes (zero is even better) increase the chances of that.

5. Do-able project.  It is fine to give a new Scrum Team a challenging project. But do not give them an 'impossible' project the first time out.  Simply because they are just learning Scrum.

Now, sometimes you have to anyway.

6. The skill sets are more fungible.  Fungible is a fancy financial term.  It means that person A is more likely to be able to do (some of ) person B's work.

We want that with Scrum.

And we want it work things can be done more 'all at once'.  For example, we don't feel that we must finish all of A before we can do any of B.

7. More likely to change.
I will use that phrase, but let me explain. Project 1 is more likely to change.

Project 2 will have less change.  And project 2 is a project that we feel confident we know how to do.  Many of the people in the team feel they have done similar projects.  And we have high confidence that project 2 will have few major surprises.

In that case, I think Scrum will help project 1 more. Because Scrum will enable the Team to learn faster and adapt faster.  For project 2, at least now, it appears that learning and adapting will not have as much value.

Still, I find it hard to say this. I have had too many projects that seemed 'stable' at the beginning, and yet when we got into it, all hell broke loose.  And there was plenty of change and learning.  So, watch out for the accuracy of your initial assumptions.  You know about how the word 'assume' works.

***

I think those are the major factors.  I may have left out one or two.  Probably I will revise this post after a few comments.

Creativity and Process

Here is a good quote:

Now I have to tell you something, and I mean this in the best and most inoffensive way possible: I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign … The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.  Elon Musk, founder of Space-X and Tesla Motors

One of the key aims of Scrum is to vastly simplify the process that you have.  The experience is that people need a bit of process.  That the sonnet form leads to greater creativity by poets.  They need a bit of structure.  But then any additional structure needs to be asked for.  Not imposed.

And this is just the way we think with Scrum.

We think Scrum provides just the bare minimum of process that actually increased creativity.

And, we think that, after that, as process is forced on a Team, is starts to reduce creativity.  The heavier, the greater the reduction.  Now, creativity isn't everything, but we think in the knowledge creation business, it is awfully important.  Perhaps the most important thing.

I saw the quote at an article discussing Six Sigma and Creativity.  That article is here.

The Team is primary

There has been a lot of discussion in the community lately about scaling.  With specific discussion of the SAFe and LeSS frameworks.

We don't have a strong opinion on many of the issues. We do think that each scaling situation is different.  We do think the music (the values and principles inside the players) is at least as important as the dance steps (the specific practices and artifacts).

One thing we do feel strongly about: the Team is primary.

Meaning, for example: It is easy for managers to think they are important. It is easy for the General to think that he alone wins the war.  But in fact, it is the soldiers who win the war. And the General's plan is always ... well, a nice piece of fiction, or a nice fantasy.

It is the innovators in the Team who do the real innovation.

Now, there can be a few key guys.  Maybe Steve Jobs was such a guy to Apple. But for most of us, the real innovation happens inside the Team.

Always keep the Team primary.

Never get so involved in SAFe or un-SAFe, LeSS or MORe so much, that divert attention too much away from the Teams.

CBA: new Maserati vs. used Lexus??

Ladies, Please forgive me. I have to make an obvious point with some guys. And you know how guys can be. Sometimes you have to make it really obvious to them.

***

We need to know the BVPs (business value points) and the SPs (Story points) of each story, so that we can do CBA (cost-benefits analysis).  And choose the right story to do next.

Why?


Now I explain the picture.

Many guys who are into cars would prefer a free Maserati.  Truly nice sports car. See the picture. 
Wow!  Is that a car or what?  Especially if it is 'free'. (It also helps that I like really smart brown-haired girls and the color blue, but we won't go there.  The things I have to suffer through to make a point!)

But it is shocking how many guys will choose a 2 year old used Lexus, if they have to pay for it (the car).  Why?  Just on initial cost, a Maserati costs about $300,000.  I think a 2 year old Lexus is close to $25,000.  Big difference in cost.

And the customers and business managers are the same way with the features in the new product.  If they can see no difference in the cost, of course they want the Maserati feature. But as soon as they can do CBA, even roughly, they start to say...."umm, I think I can live with the used Lexus" feature.

CBA is also a way to convince them to do the right thing. Release earlier. And then the Team looks like a bunch of heros. Rather than suffering a Death March. (I am surprised that that picture could make regular guys turn into heros.  But I think it could be true.)

Question: How to order Stories in the PB

Question from a former Class Attendee:

Another question, this time about ranking user stories.

In the recent Scrum Master course, you indicated we should rank stories in the PB (Product Backlog) by Business Value and then do them from the top down. In the Product Owner course back in 2011, you had us calculate R = BVP / SP to arrive at the cost / benefit value and then rank by R. This would have the effect of doing longer items ahead of shorter items that have somewhat less business value.
What do you recommend now? What are your current thoughts?

Reply:

I explain this at a decent length in my small book on Agile Release Planning.

I am still a fan of the R factor.  AKA cost benefit analysis.

And a fan of making stories small.  To me, all epics eventually must be broken down so that we can get 8 items (stories) in a sprint.  So, if we have a velocity of 20 for a 2 week sprint, then items average about 2.5 story points in the sprint.

So, as stories rise to the top and get broken down, we have to re-point (both BVP and SP). And thus the R and the ordering will change.

Not quite sure what your concern is, but I think that resolves it.


The order can never be 'purely' business value.  We have other things to consider (which we might also call business value, but to me it gets too complex to put it that way....).  Things like Risks, Dependencies, Learning, MMFS (minimum marketable feature set), and Other factors.

So, I like to use R factor. Rank by that. And then have the Team discuss changes to that ordering.
Remember that to me the most important thing is that the Team together see the same elephant.

In the long term (or short term??) the PO wants to maximize the business value delivered out of the Team.  I think.  As a contrasting example, the PO is not optimizing the 'efficiency' of the Team (that each hour is used 'productivity').

Help?

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.

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.

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.

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

Killing Babies or Sizzling Steak

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.

Business Value is a dream

There is a famous Taoist story about a person dreaming that he is a butterfly. And awakens and can't decide: Am I person who dreamt I was a butterfly, or am I a butterfly dreaming I am now a person?

This is not the kind of dream I meant, when I used that word in the title.

"We are such stuff as dreams are made on..." This is more the kind.

Business Value is based on what people want. And I think that what they want is, for good and bad, mostly a dream. That is, they imagine they have a problem, and they dream of the 'perfect' solution. Well, perfect in the sense of the best they can dream. And it is this dream that they want.

So, we, who spend our lives trying to fulfill the customers' dreams, must accept that it is all about dreams. Dreams can change. Nightmares come and go.

And in our dreams as implementors (not customers), if we are as good at dreaming as, say, Steve Jobs, we will imagine the yet-more-perfect solution to the problem. Example: The iPad.

Some of us a very practical. This leads to many good results. But in dealing with dreams, perhaps we practical ones should dream more seriously.

Some people say that Business Value is all about money. But before the money, they must want to buy. And that is dreaming. That is evanescent. And yet it becomes brutally real. (Cf Motorla Zoom just about now. I think.)

Understanding the customer

In my viewpoint, one of the key things about Agile is bringing the customer and the Team (the implementors) MUCH closer together. So that the Team starts to understand many (most?, all?) of the marketing issues and activities. In effect.

Let me mention two things.

1. While the customer usually knows their own problem (well, pretty well), they typically are rather clueless about what the solution should be. Nonetheless, we typically ask them 'the requirements', and we are shocked, shocked later when they say "Well, now that I see it, it is not what I want."

As one angle to this, most normal people don't want 'a product'. They don't want software or a technology gizmo (yes, there are a few people who do want this, but they are few). They want only what the product will bring, ie, that the problem will go away. As an example: they don't want a music playing thingie (Zune or iPhone), they just want to be able to hear the music they want almost anytime they want to. (Yes, the 'problem-solution' metaphor does not work well in every case.)

Along with this, the customer is a normal human being; meaning, even what they say is not very articulate.

As a perhaps not minor point, no two customers agree.

2. We can't hear what the customer says. This is of course normal human behavior, as, for example, any wife (or husband) knows. And there are also lots of additional root causes for us.
* we put extra people (noise) in the process.
* our topic is very abstract
* we are talking about something that does not even exist yet
* it has all kinds of geeky, fast changing, fast moving lingo around it
* we want to hear features, and the customer wants to talk about his problem
Etc, etc, etc.

To improve this situation, Agile says: Bring 'em much closer together. Even closer than we can possibly imagine. Far from perfect, but hopefully most of the time much better.

(Why still imperfect? Well, for example, even a husband and wife who have been together for 20 years don't perfectly understand each other. As another example, most business-customer types are challenged hanging out with techno-geeks talking a different language.)

Now, it is still terrible, so I think we should enable ourselves to discover more quickly when the cycle is especially stupid.

So, I am suggesting putting in a tight P-D-C-A cycle in there (Plan, Do, Check, Act). That cycle in Scrum is a Sprint and then a Release (ie, two cycles).

With some metrics (which are indeed very hard, but hey, delivering business value is what's important). Example: measuring the BV delivered after each release with some metric. We will still make lots of mistakes, but maybe we learn faster.

Additional Value from the Scrum course

In the prior post, I spoke of a simple way of measuring the value of a scrum course. And the real subtext was: You must measure velocity (productivity) and you must increase velocity dramatically. (And, oh, by the way, a course might help you do that.)

But aside from velocity, does the CSM course provide other values?

I think yes.

So, what might they be? I would be very interested to hear how you would put this (or these).

X has already mentioned that it bring a common terminology. This is very helpful. In many ways, and to many different people.

I have heard a senior manager say: "If they only thing I get is greater visibility into where we are, that's plenty. I don't have to have anything else get better." And while the Scrum course won't guarantee that, one of the main benefits of Scrum is that, if you do it right, everyone gets greater visibility. [Now, we are concerned that some managers will meddle more, in a hurtful way, if they get greater visibility, but almost always the meddling goes down some, at least.]

People work less in isolation. I think this is a big improvement. It is a more humane way of working, in this way. Less lonely.

Teams are held accountable for something important, rather than an individual being held accountable for something fairly unimportant and outside his/her control. This is, in general, a big improvement. There are issues, and there are ways that Scrum still holds (appropriately, I think) individuals accountable, so this needs further discussion, but in general, a clear improvement.

More fun. Scrum says that the team must be having fun (well, mostly fun) or its not being done right. And, if it is done with "right" limits, it is always more fun (or so I have found). To me, this is a value on its own.

More focus on impediments. The PMI folks might argue that we always were working impediments, and of course in some sense this is true. But Scrum brings a lot more rigor and effective action and focus on the top impediment, one at a time. Everyone can contribute, the team can identify and prioritize them and devise a plan to remove each one. Even if we don't measure velocity, this is a big value add in many ways (eg, more satisfying and less painful way to work).

So, that's a start. Hardly a complete list of the value. But a start.
You could say that these start to explain how Scrum "magically" leads to greater velocity and a higher delivery of Business Value.

Value from the Scrum course

I wanted to reiterate views I have expressed elsewhere, I think.

My best guess is that a typical development team of 7 or 8, including the product owner and the scrummaster, costs about $1 million per year. Including all related costs. (In my opinion, every team should know their total annual cost.)

My best guess is that a typical development team can produce about $3 million per year in Net Present Value. Based on what they develop; ie, their share of the "earnings" from the product. This is discounted over the 3-5 year typical time horizon. (In my opinion, every team should be given an estimate, and some data after the fact, of the value of the work they will be doing, say, over a year. This concentrates their minds wonderfully.)

From a Business Value viewpoint, the goal of the Scrum course is to significantly increase the productivity of each team. So, let's assume the whole team comes to the Scrum course. And some related managers. Let's assume the team can double their productivity (their velocity) within one year. Let's assume in years 2 and 3, they continue to improve. So, saying we go from a NPV of $3 million per year to $6 million per year is not a stretch.

Let's say that there are other costs/factors that also contribute to the doubling (coaches, impediments removals, etc). So that the Scrum course, which teaches 3 teams, only gets 25% of the added value. 25% of $9 million is: $2.25 million. (Does the scrum course deserve more or less than 25%? You judge.)

Now, get out your spreadsheet and calculate the value for yourself, with your own assumptions. See XLS file here. Let me add that there are many other benefits, but let's ignore those for now.

By the way, a decent team (not a great team) in Jeff Sutherland's opinion should be able to double velocity in 6 months. Many do in 6 weeks. And some companies are seeing an improvement of 5x-8x for every team and it happens quickly.

A couple more things to say:

1. The purpose of the course is not to convey explicit knowledge, although that happens. The key purpose is to get the people willing, wanting, and waiting to change. "It's the Tacit Knowledge, stupid." (To play with a political quote from the past century.) Without this change, which always happens somewhere else than the brain, no worthy improvement will take place.
2. The team must be having fun. I won't explain that more here.
3. The team must be working reasonable hours (40 or less in total).
4. Thus, the way to velocity improvement is by impediment removal.
5. And thus, managers must be removing some impediments (and letting the team self-organize) or the full amount of improvement won't happen.
6. Finally, this is still not a silver bullet. Teams can be dysfunctional and projects can still be impossible. (The good news is that these serious problems can be identified very much sooner.)

Now, our challenge to you. Have you achieved a measurable and believable increase in your own baseline velocity? How much?

You owe it to yourself, your teammates, your company, your customers, and right now to the world economy, to get your team going. You can do it. If you feel you can't change your organization, first, don't believe yourself. "The culture" can resist one or two people. It cannot resist a fired up group that is right.

Still, if you can't change your organization, then you must change your organization. And then double there. You will be proud of yourself when you do it. You know you can. We know you can; we cheer you on.

Doubling is not enough, but like 12 lawyers at the bottom of the ocean, it's a good start.

The best work?

I just got an email where someone said that their group does not have a real project-type project. This got me thinking.

Key idea: How do we know our Agile teams are getting the best work?

It seems to me we have the theory that, magically, "the users" will ask us for the best work we could possibly do.

So, let's parse this a bit. The users might be the business or management or the customer. And the best work might be the most important thing we could do, or the most valuable or the highest business value, etc.

OK, so as soon as we make transparent the hypothesis we can see at least 4 holes.

1. The users are always human, and almost never can identify the highest value things. Consistently, reliably.
2. Identifying the highest value things (product, project, story, whatever) is, in large part, cost-benefit analysis. Only if the decision maker has complete understanding of all the benefits and all the costs (risks), can she make the best decision. If we technologists don't tell the business folks about the costs, how can they possibly give us the best stuff?
3. Do you know what you are really capable of? For sure, most business guys do not know what technology is really capable of. And they don't know what your Dev team is capable of.
4. Are we technologists capable of keeping up with all the extensions inherent in existing technology? Or keeping up with technology innovation? Even less can the business guys do that.

How do we fix this mess?

The issue here is that, although we are doing important work, we are still "failing" if it is not the most important work.

Well, I will suggest we need to get business and technology people together more, and the technologists need to ask: "How could we be more sure that we are getting the best work... so we, together, can make the greatest possible contribution around here?"

There are about 250 business days each year. I bet there are 250 ways to phrase that question.

Defining Business Value // #2 Customer Smile

Imagine that you want to make a new camera. And in the first release you will make 1,000 cameras and basically "give them away". Give them to key influencers, etc. So, all that that work does is make the customer smile.

Imagine that the picture here is not of Scarlett Johansson. Just a girl. And it represents all 1,000 customers who buy your new camera. You don't make any profit, just the smile. In fact, you lose $10 on each camera.

How do we evaluate the Business Value of that smile? Or those smiles. There are many ways one could approach this problem. Without explaining all my assumptions, let me quickly say this.

Well, presumably the smile is worth something later. You provided customer satisfaction, and they will come back and buy the next camera from you. Or tell their friends to, etc, etc. If you were clever you could estimate that.

But let's imagine that the Product Owner is not that clever.

Let's imagine you have 5 stakeholders, stakeholders who understand the business intuitively and have lots of experience of Business Value in all its aspects. Let's imagine that you have them to vote on the BV.

Earlier I recommended getting the list of stories for building this new camera, and having these experts play priority poker for those story cards. Relative value compared to a small reference card of 1 (the card that you all initially think has the least BV). Using the Fibonacci series up to about 1,000.

You do this exercise, even though the real number you need for business decision-making now is the total dollar value of the effort (eg, to judge whether to invest here or elsewhere).

Why do that? So that the team of 5 creates knowledge together about what the effort really is. If you are already sure they have a common view of the effort, and a fair amount of detail about it, then maybe you don't take this step of priority poker yet (eg, until after the project is "approved").

OK, now to estimate the overall dollar value.

Again, there are other techniques, but the one I will recommend first is have each of the Delphic experts write down their personal opinion on a piece of paper. Before being influenced by anyone. And some comments about why "my" number is right.

And then all flip the cards at once. And compare. The two extremes talk most, about why each had the highest (or lowest) number. The assumptions, and the issues they see with the other extreme. They might compare to previous efforts. "Project X had $20 million and I just don't see this as better than Project X, so I don't see how you can get to $24 million." Maybe they vote again, and eventually reach some closer consensus. Maybe they discuss again, and vote a third time. Then, however close they get, average the answers they give. Use that.

There is no harm if one or more of the "experts" wants to use a mathematical formula of some sort. They should share that formula.

You might, particularly in the first few months of using this technique, have a senior manager do a "sniff test". They bring him in and say "We decided this effort is worth $17 million, plus or minus about 100%. Seem reasonable to you?" If he can accept it as probably the best guess at this time, then they did a good-enough job. Or they might take his input, do a bit of scratching of the head, and estimate again.

Finally, as they get closer to production, someone should be working on a formula for BV, and how to prove, or at least get indicators about, whether that formula is relevant. Let's say a key aspect of the formula assumes that 900 of the first 1,000 users have a broad smile. So, they might use the Net Promoter Score to confirm that assumption. Etc, etc.

BV is hard. Like any prediction of the future, it is difficult, and likely to be off. Still, we need to learn how to be less and less off in our estimates. While all estimates are "terrible" compared to the precision of what reality will later give us, still it is better to make business decisions with the best info we have today than with no info at all. Even though very imprecise, and sometimes inaccurate (leading us in the wrong direction). Making no business decisions is not an option.