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

August 12, 2022

Better

Let’s agree on the obvious: 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.

And that mainly means two things: more fun and better results. Better business results (and they 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. We treat you like an adult. 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.

BVPs – Business value points
SPs – Story points
Fun
Motivation
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 too fast for some people. So, please feel free to ask questions about anything that is not soon obvious to you. I really should explain each in depth. And only then try to integrate them. So, apologies if I lose you. Again, happy to come back and explain.

Note on convincing: Usually, words are insufficient. You need to see the things in practice. And if implemented …not well…you might not get good results. Convincing a skeptic is tough.

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.

And 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 (ok, to misquote Einstein: Things should be as fast as possible, but not faster).

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 (like 50 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 number. Well, as rough and incomplete and imperfect as our current knowledge of the Future (and other things).

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

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

And now, we have transparency. Anyone can see what we voted. Anyone can give us feedback (often VERY useful). And we learn. Faster.

And the priority poker was a game.

Note: As they learn more, they can re-vote the BVPs on any story. And that is commonly done.

Story Points

A Game. The game of story-pointing.

The 5 Developers vote. (Well, typically 5.)

We set a reference story, and at an abstract level, we vote in comparison to the reference story.

Again, a game. Fun. Learning. For about 1 hour for all of them. Pretty fast.

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

Now “we all know what we all know”. (Well, a bit of an exaggeration, but that’s the aim, and so is accomplished to a fair degree.)

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. Learn. And then revise the numbers to get better.

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.

People have issues with story-pointing. We can discuss them.

Fun

We have mentioned fun several times already.

By now it is clear. This is not stupid 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 feel about planning in waterfall…or even in their “agile”).

Less stress, most honesty. More adaptability. Etc Etc Etc.

Motivation

Very low or no fun is de-motivating. Not good.

And, more generally, we want to remove all the de-motivators.

But in a positive way, 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 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”. No longer “kept in the dark”, they see it.

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

The Plan

They use the BVPs and SPs, to calculate an ROI for each story. Or R (ROI) index. Benefit (BVP) over cost (SP).

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

And order the Product backlog by ROI. Highest first.

And anyone can propose other reasons for re-ordering the Product Backlog. Ex: Dependencies, Learning, Risks, MMFS/MVP, etc.

We use this Product Backlog to lay out the stories into Sprints. Based on expected Velocity (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 they are (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 that, initial. 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. If they are successful.

Do not underestimate the long-term importance of doing this frequently. Success breeds success. If they do these things with some skill, they should mostly be successful, at least to some degree. (Yes, I know it depends on the situation. But this is what I think of as a normal situation.)

Pareto’s 80-20 Rule

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

And 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 get 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 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 you can do this, then… Faster releases (less work). Better releases (higher BV). Faster learning (due to faster releases). More learning about what BV really really is. More chances for the customers to tell you what they want, what they really really want, now that things have changed (these days, so much).

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 (probably) alternate ideas about what real success is.

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

If you do it now (or much or some), how well? And what could we discuss to help you improve?

If you are thinking about doing it, again what would be useful to discuss further?

There is also a discussion of how these things differ from alternate ideas that are out there in ScrumLand.

Happy to discuss. Please add comments or contact me.