BVPS, SPs, Fun and Pareto – A few ideas toward better agile

Better

Let’s agree on a few things: The most important thing (that we will discuss) is a better life.  For each of us, for the Team, for our customers, for the organization, and more broadly.  And, we think better agile will help that.

There is no doubt in my mind that we, virtually every team, can be doing notably better agile.

In fact, in our opinion, continuous improvement is an axiom, and we should always be practicing it.

That mainly means two things: more fun and better results.  Better business results (which can be defined in many ways).

So, today I want to talk about some ideas for getting there.

These are not the only ideas.  These might not be the best things for you to do today.  Let’s deal with this as adults.  We make some suggestions; you must decide whether or when you act on them.

The Group of Ideas (Practices)

Here is the set of things for today.

1. BVPs – Business value points
2. SPs – Story points
3. Fun
4. Motivation
5. The Pareto Rule (80-20)

We hope you will see here some new and different inter-relationships between these five things.

And that you’ll see how you can do them better.

These are actually complex ideas, each, and we are going pretty fast. So, please feel free to ask questions about anything that is not soon obvious to you.  Each should be explained in more depth.  Then, you must integrate them.  So, apologies if I lose you.  Again, happy to come back and explain.

Note about becoming convinced: Usually, words are insufficient. You need to see the things in practice.

Business Value Points

Let me go through each quickly.  Starting with Business Value Points.

BV pointing is a game to enable learning.  That’s where we start.

The game makes it fun.  And learning is the result.

In new product development, you might say that the only thing we do is learn.  It is always about the future.  Yes, we want to satisfy customers and make enough money in the here and now.  But we always need to learn about the new future, all the changes, and what the product(s) must then become.

It is somewhat stressful, so fun.  We need learning, so fun.

We find the five best people we can (PO plus four business stakeholders).  And we PLAY priority poker.

Next key idea:  KISS.  Keep It Stupid Simple.  And fast.

And it’s mainly about the conversations.  But the numbers help too.

We identify the reference story for BV.  Give it 100 BVPs.  And vote on the other stories quickly (about 50 stories in 1 hour or so).

Then we can prioritize our stupidity. What do we know pretty well (maybe good enough), and what learning would help a LOT about now.  After the votes, we expect where we want to learn becomes clearer.

Also, we have a rough BVP number.  Well, as rough and incomplete and imperfect as our current knowledge of the Future (and other things).

We have shared the Tacit Knowledge with these five people (and anyone else who listened in).

We have a BVP number (for each story) that reflects the “wisdom of the team.”   They were the best people we could find.

We have transparency. Anyone can see what we voted.  Anyone can give us feedback (often very useful).  And we learn faster.

Again, priority poker is a game.

As they learn more, they will re-vote the BVPs on any related story.

Story Points

A Game.  The game of story-pointing or planning poker.

The 5 Developers vote. (We recommend 5 Developers.)

We set a reference story, we vote in comparison to the reference story.

Again, a game.  Fun. Learning.  We vote for about 1 hour for all 50 or so stories. Pretty fast.

Again, sharing Tacit Knowledge across all the members of the group (and others) is a key benefit.

Now “we all know what we all know.” (Well, a bit of an exaggeration, but that’s the aim.)

And we can now prioritize our stupidity.

We do not wait for perfect information.  We vote with what we have now.

And then prioritize our stupidity.  Prioritize our next learning. And then re-vote the numbers as we get smarter.

Note: Not only is story pointing fun (with the right people and attitude), it also should be used to help set realistic expectations. And keep the Team in a reasonable zone for stress.  Sprint by Sprint they see more success, and that builds Team morale.

Some people have issues with story-pointing.  We can discuss them.

Fun

We have mentioned fun several times already.  We won’t discuss this at length here.

We are not recommending sophomoric silliness.  This is the stuff that makes us happy. Serious fun, mostly.

Fun helps in many ways.  Planning becomes fun, which is the opposite of how many people initially feel about planning.

Less stress, most honesty. More adaptability.  Etc.

Motivation

Very low or no fun is de-motivating.

Generally, we want to remove all the de-motivators.

On the positive side, we want to enable the team (including the business stakeholders) to become more motivated.

Understanding Business Value better will help.

Not feeling “under pressure” will help.

Seeing how all the work falls into Sprints, and then how we can accomplish a bigger goal.  Getting a sense that this is realistic and doable.  All these improve motivation.

Particularly, it should help that they “see where we’re going.”  They no longer feel “kept in the dark.”

They also love the transparency.  And the encouragement to contribute to the plan. The plan becomes “our baby.”  They feel ownership.

The Plan

They use the BVPs and SPs, to calculate an ROI for each story.  BVP / SP is a rough ROI index. Benefit (BVP) over cost (SP).

It’s simple and quick.  A rough indicator.  With our current knowledge.

We order the Product backlog by ROI first.  The highest number first.

And anyone can propose other reasons for re-ordering the Product Backlog away from ROI.  Going only by ROI would be wrong, to some degree, every time.  Other factors would include: Dependencies, Learning, Risks, MMFS/MVP, etc.

Then we lay out the stories into Sprints.  A Sprint holds X stories based on the expected Velocity of that Sprint. (Or average Velocity, once we have it).

We add Contingency and what I call Landing Strip — the Final Testing and other work we must do to “Ship It” (or whatever phrase you use).  Now we can see all the work needed to get to done-done-done for the first (next) release.

The Goal

You could argue about the goal or goals.   Let’s say we want (a) a better Team, (b) a (more) wonderful product for the Customer, and (c) business success (however you define that).

And one related goal is learning.  So, the initial Plan is only a start.  We use the initial plan to help us learn. And every Sprint, with 7 or 11 people learning, we have learned enough to revise the plan.

The bad news doesn’t get better with age, as you may have heard me say.

So, the revised plan, if only a less inaccurate prediction of the future, is still helpful to the Team and to the Manager.

One more goal: The Team (metaphorically) gets to sing “We Are the Champions” along with the business side folks.  When they are successful.

Do not underestimate the long-term importance of frequent small wins.  Success breeds success.  If they learn to do these things, they should mostly be reasonably successful.  (Yes, I know it depends on the situation.  But this success should be normal.)

Pareto’s 80-20 Rule

I now want to add one more key thing to this discussion.

There are MANY other possible things to add.  Ex: One could add Lean Start-Up to this.  Or Lean Thinking.

As many know, the 80-20 idea is that we can choose 20% of the work, and that will yield 80% of the value.

How do we do that?

We have a Product Backlog ordered mainly by ROI.   So, what we want to do, if we can, is select some small stories (or maybe smaller ones than we have now), and find 20% of the work (the story points) that gives us 80% of the BVPs.

And, if you have ROI on each story, this task becomes much more visible to the PO.

And if the PO and the Team learns do this, to think this way all the time, then good things happen.  Faster releases (less work).  Better releases (higher BV).  Faster learning (due to faster releases).  More learning about what BV really really is.  (That is, even when they choose wrongly, there should be learning.) More chances for the customers to tell you what they want, what they really really want now that things have changed.

Afterword

OK, I tried to explain the ideas and practices quickly here; definitely incompletely.  And also explain many of the interconnections and reasons why these things can be successful.

And even snuck in some alternate ideas about what real success is.

It is incomplete. It probably requires you to think a lot.

Please give me your feedback (probably best via email).

Please try them. And please give me your feedback then.

Happy to discuss.  Please add comments or contact me.

I wish you and your Team every success.  You can do it.  You can get there.

« « Commonalities and Differences || Fixing Agile Transformations – 1 » »