[SCRUMDEVELOPMENT] Metrics for Product Backlog

[[e-mail] [SCRUMDEVELOPMENT]]

Hello,


PO is said to be responsible for maximizing the value of the product and work of the team, and SM is to help her.


But how to 'measure' effectiveness of product backlog management? The goal behind the question is to understand if PB can be managed more effectively.


Is there any set of metrics that can answer the question?



I know people use Lead / Cycle time etc, but it may be there are others there in the wild that I've never heard of.

[[e-mail] [SCRUMDEVELOPMENT]]

Hi


What do you want to use these metrics for? To measure the effectiveness of the PO? To give some indication that the PO could be doing better? To compare different POs?


The effective management of the PB comes from ordering the PB items by business value (with advice from the team on technical dependancies).


I would suggest that improving the measures of calculating PB item business benefit would be a better subject to spend your time on.


If you do want to compare POs -- DON'T -- they are working with different products!!


Just my thoughts


Steve

[[e-mail] [SCRUMDEVELOPMENT]]

Hi, Steve,

In no way do I want to compare POs!


As I wrote I'm interested in understanding how PO can do better with product backlog.


Prob some trivial example, if PO keeps pulling to the top low severity bugs instead of more valuable critical bugs, that I'd say something could be done differently. Or, as another example, if some PBI has been too long on backlog (lead time) and so on. One more example could be PO spending too much time on 'detailing' PBIs deep down the backlog


I would suggest that improving the measures of calculating PB item business benefit would be a better subject to spend your time on.
Can you suggest such measures? Anything in particular you meant there?

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi, Steve,
In no way do I want to compare POs!
As I wrote I'm interested in understanding how PO can do better with product backlog.
Prob some trivial example, if PO keeps pulling to the top low severity
bugs instead of more valuable critical bugs, that I'd say something
could be done differently. Or, as another example, if some PBI has been
too long on backlog (lead time) and so on. One more example could be PO
spending too much time on 'detailing' PBIs deep down the backlog
I would suggest that improving the measures of calculating PB item
business benefit would be a better subject to spend your time on.
Can you suggest such measures? Anything in particular you meant there?

Sales. Profit.

[Joshua Partogi [e-mail] [SCRUMDEVELOPMENT]]

If that is the case then the only way you know whether the PO has managed the PB effectively is after the product is released. Unless the product is released, you don't really know whether the PO has managed the PB effectively. If your customers scream then it is not the right PB to be developed, it your customers give praise then it is the right PB to be developed. I like using AARRR metric for that reason.


Kindest regards,
Joshua Partogi
http://www.leanwithagility.com






From: ***@yahoogroups.com
To: ***@yahoogroups.com
Date: Tue, 26 May 2015 08:39:38 -0700
Subject: [SCRUMDEVELOPMENT] Re: Metrics for Product Backlog














































Hi, Steve,


In no way do I want to compare POs!
As I wrote I'm interested in understanding how PO can do better with product backlog.
Prob some trivial example, if PO keeps pulling to the top low severity bugs instead of more valuable critical bugs, that I'd say something could be done differently. Or, as another example, if some PBI has been too long on backlog (lead time) and so on. One more example could be PO spending too much time on 'detailing' PBIs deep down the backlog
I would suggest that improving the measures of calculating PB item business benefit would be a better subject to spend your time on.Can you suggest such measures? Anything in particular you meant there?

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hennadii,

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Prob some trivial example, if PO keeps pulling to the top low severity bugs instead of more valuable critical bugs, that I'd say something could be done differently. Or, as another example, if some PBI has been too long on backlog (lead time) and so on. One more example could be PO spending too much time on 'detailing' PBIs deep down the backlog

Why wouldn’t a simple chat with the PO sort this out, if it ever happened?

Ron Jeffries
www.XProgramming.com <http://www.xprogramming.com/>
Sometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better.
Of course you might plummet to the earth and die, but probably not: you were made for this.

[[e-mail] [SCRUMDEVELOPMENT]]

Ron,

Well, first of all you have to know what to talk about, and that's what I'm after - to understand what is less efficient that it may be.

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hennadii

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Well, first of all you have to know what to talk about, and that's what I'm after - to understand what is less efficient that it may be.

I don’t understand. Why do you need a metric to know what the PO is doing?

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Before I start arguing with somebody, I try to save them a little time by letting them know that I’m usually right about stuff.
— Andy Richter

[[e-mail] [SCRUMDEVELOPMENT]]

Ron,

"What is PO doing?' is not my question though. My question is 'What could PO be doing more efficiently?'


If suppose Lead time can help answer that question, than to have lead time, I have to 1) know Lead time can help 2) measure it.

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

Lead/Cycle time does not measure quality or value, just speed. If all you
cared about was speed, you wouldn't need any process at all. What end
result are you trying to get out of these metrics? You say efficiency, but
I'm not sure that the goal of the PO is to manage the PBL "efficiently".
It's to maximize value and quality. Maximizing efficiency is often at the
detriment of value or quality.

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Ron,
"What is PO doing?' is not my question though. My question is 'What could
PO be doing more efficiently?'
If suppose Lead time can help answer that question, than to have lead
time, I have to 1) know Lead time can help 2) measure it.

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hennadi,

Post by ***@gmail.com [SCRUMDEVELOPMENT]
"What is PO doing?' is not my question though. My question is 'What could PO be doing more efficiently?'
If suppose Lead time can help answer that question, than to have lead time, I have to 1) know Lead time can help 2) measure it.

If you know what the PO is doing, why don’t you know whether it makes sense or can be improved?

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
If another does not intend offense, it is wrong for me to seek it;
if another does indeed intend offense, it is foolish for me to permit it.
-- Kelly Easterley

[Dan Greening [e-mail] [SCRUMDEVELOPMENT]]

A simple test for good PO behavior would be Turing incomplete or worse
"prescient". Product Management is necessarily complex, otherwise everyone
would be inventing something new that was instantly loved by millions.

However, there are some practices that can help. I think
http://senexrex.com/pattern-product-owner/ reveals some, particularly the
idea of a "geometric backlog", that allow team members to quickly view a
proposed future and consider it as they are writing short-term code.

Hope this helps.

Dan R. Greening — http://dan.greening.org http://linkedin.com/in/greening

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
Hennadii,
Prob some trivial example, if PO keeps pulling to the top low severity
bugs instead of more valuable critical bugs, that I'd say something could
be done differently. Or, as another example, if some PBI has been too long
on backlog (lead time) and so on. One more example could be PO spending too
much time on 'detailing' PBIs deep down the backlog
Why wouldn’t a simple chat with the PO sort this out, if it ever happened?
Ron Jeffries
www.XProgramming.com <http://www.xprogramming.com>
Sometimes you just have to stop holding on with both hands, both feet, and
your tail, to get someplace better.
Of course you might plummet to the earth and die, but probably not: you were made for this.

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

Imagine you had a team about the size that Scrum and XP recommend. Given
that, if you want to know how the PO is doing you ask him/her. [After this
follows a long conversation about scale, 18th century management theory,
and how software is different... you will have to pay me if I have to have
that conversation again.]

Post by Dan Greening ***@greening.org [SCRUMDEVELOPMENT]
A simple test for good PO behavior would be Turing incomplete or worse
"prescient". Product Management is necessarily complex, otherwise everyone
would be inventing something new that was instantly loved by millions.
However, there are some practices that can help. I think
http://senexrex.com/pattern-product-owner/ reveals some, particularly the
idea of a "geometric backlog", that allow team members to quickly view a
proposed future and consider it as they are writing short-term code.
Hope this helps.
Dan R. Greening — http://dan.greening.org http://linkedin.com/in/greening

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
Hennadii,
Prob some trivial example, if PO keeps pulling to the top low severity
bugs instead of more valuable critical bugs, that I'd say something could
be done differently. Or, as another example, if some PBI has been too long
on backlog (lead time) and so on. One more example could be PO spending too
much time on 'detailing' PBIs deep down the backlog
Why wouldn’t a simple chat with the PO sort this out, if it ever happened?
Ron Jeffries
www.XProgramming.com <http://www.xprogramming.com>
Sometimes you just have to stop holding on with both hands, both feet,
and your tail, to get someplace better.
Of course you might plummet to the earth and die, but probably not: you
were made for this.

[[e-mail] [SCRUMDEVELOPMENT]]

Hi again


Thanks for the clarification but I still say it is all about busines value.


Your example says it all really; it would indicate to me that the PO, for some reason, thinks that simple, quick PBI are better to be done than other PBI.


Are you sure that the'quick wins' are not also the most important business value things?


Agreed it is not always simple to to put an absolute number on business value but relative value can be useful in 'bubble-sorting' the PB ie is this PBI more important to the overall business than this one.


To stick with your example, is the PO being 'measured' by someone 'requiring' the fewest bugs in the product? If so, it is not the PO that necessarily needs to improve but the management for being too simplistic and anti-Agile.


Any better?


Steve

[Avi Naparstek [e-mail] [SCRUMDEVELOPMENT]]

"
The goal behind the question is to understand if PB can be managed more effectively.
"

I'd ask - More effectively than what?
What's you're baseline that you want to improve right now?

Avi

[[e-mail] [SCRUMDEVELOPMENT]]

Avi,

Baseline is current state. Actually that's partly why I asked for the metrics in the first place - to know the baseline


Steve, Dan,


Thanks for your suggestions. Your answers directly addressed my question which seems to be happening not that often :)


Thanks to others, too, how tried to persuade me that I don't need to ask such silly questions

[Avi Naparstek [e-mail] [SCRUMDEVELOPMENT]]

"
The goal behind the question is to understand if PB can be managed more effectively.
...
Baseline is current state. Actually that's partly why I asked for the metrics in the first place - to know the baseline
"

I know this might sound way too Yoda on my part, but notice your words and mine.

You were asking how to **manage the PB more effectively** - this implies you need a metric not of how fast or at what quality the product is actually being delivered (that is delivering products more effectively, not managing the PB) but rather a baseline metric of how well the PO is doing his job (which is to manage the PB).

Two very different things.

So which is it you're after?

All the best,
Avi