Committment Based Planning?

[Scrummistress]

Folks - recently some new product owners in our company came back from
training with a new spin on Sprint Planning they called Committment
Based Planning. I'd like to hear from the industry on this and see if
anyone has any documentation and/or experience with this? The way it
was explained to me is taking a focus off using the velocity history
to load a sprint, but I'm struggling with how the team would realy
understand it's capacity without using the context of velocity.
Wondering if there is something that was missed in the translation.
Who can lend some info on this subject?

Appreciated....

L

[Julie Hendry]

Have seen this where PO prepares sprint goals and the teams decide which goals they can commit to. All the usual po q and a but without the detailed stories and task planning is optional or on the fly. I would not recommend this for a team without velocity working on fixed dates nor if the team and po have comms issues in the recent past. This is very much reliant on trust and commitment values :)

Julie

> --
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>
>

[Brian Swan]

I've used commitment based planning for the first sprint when you have
no velocity data, then use velocity based commitment for subsequent
sprints.

Brian Swan
http://www.agilewebtraining.com

[RonJeffries]

Hello, L, very efficient name you have there ...

I guess I'd want to know who they heard it from and what they think they heard.

If I used the term -- and I might -- I would mean that the team determines what stories they can take on by looking each other in the eyes and deciding how much they can do, and then committing themselves to doing that. (Up to some level of "commitment", of course. They're not supposed to die trying.)

The team will of course reflect on how much they've done in the past. They will of course reflect on and discuss how hard these stories seem to be. What they will not do is keep some numeric score of how much work they can do. They will not assign arbitrary or meaningful numeric units to stories. 

The team assigns points to stories based on judgment in the light of experience. The commitment approach skips over the points and still relies on judgment in the light of experience. It adds in the notion of a mutual commitment, and subtracts out any numerology and reduces the possibility of pressure either in the Sprint or elsewhere to "improve the numbers".

What questions come to mind now?

Ron Jeffries

www.XProgramming.com

I know we always like to say it'll be easier to do it now than it

will be to do it later. Not likely. I plan to be smarter later than

I am now, so I think it'll be just as easy later, maybe even easier.

Why pay now when we can pay later?

[Michael James]

On Feb 2, 2012, at 4:35 PM, Scrummistress wrote:

> The way it was explained to me is taking a focus off using the velocity history to load a sprint,

It sounds like this is being presented as something new. But velocity wasn't part of Scrum to begin with, and commitment was.* It seems to me the burden of proof is on those who advocate teams replace their collective professional judgment with a bunch of made up numbers. Using velocity history to load a Sprint strikes me as a step away from taking responsibility.

What Ron said, in other words, except my words might sound less kind than I'm intending them to.

--mj

* at least until the recent Scrum Guide update

[Aspen R]

Ron said:
> If I used the term -- and I might -- I would mean that the team determines what stories they can take on by looking each other in the eyes and deciding how much they can do, and then committing themselves to doing that. (Up to some level of "commitment", of course. They're not supposed to die trying.)
>
> The team will of course reflect on how much they've done in the past. They will of course reflect on and discuss how hard these stories seem to be. What they will not do is keep some numeric score of how much work they can do. They will not assign arbitrary or meaningful numeric units to stories.

Phrased this way, this is my company. We have difficulty determining
our velocity--it's a long story involving one backlog for maintaining
and expanding 4 or 5 products at a time, as well as teams with
constantly shifting membership--and hence we always come back to
trusting our gut and each other.

Therefore I submit that "Commitment Based Planning" = trusting your
gut feelings and those of your trusted team members. (Yes, several of
you basically already said this. =)

Now, should we be satisfied with doing it this way or should we be
trying to add the sanity check of velocity numbers? That is the real
question.

Personally, we tend to be overly optimistic, so I'm in the process of
devising a system to track and predict our velocity.

[George Dinwiddie]

Aspen,

On 2/3/12 1:56 PM, Aspen R wrote:
> Ron said:
>> If I used the term -- and I might -- I would mean that the team
>> determines what stories they can take on by looking each other in
>> the eyes and deciding how much they can do, and then committing
>> themselves to doing that. (Up to some level of "commitment", of
>> course. They're not supposed to die trying.)
>>
>> The team will of course reflect on how much they've done in the
>> past. They will of course reflect on and discuss how hard these
>> stories seem to be. What they will not do is keep some numeric
>> score of how much work they can do. They will not assign arbitrary
>> or meaningful numeric units to stories.
>
> Phrased this way, this is my company. We have difficulty determining
> our velocity--it's a long story involving one backlog for maintaining
> and expanding 4 or 5 products at a time, as well as teams with
> constantly shifting membership--and hence we always come back to
> trusting our gut and each other.

My experience suggests that you might do better keeping the teams whole,
and bringing the work to them.

> Therefore I submit that "Commitment Based Planning" = trusting your
> gut feelings and those of your trusted team members. (Yes, several of
> you basically already said this. =)
>
> Now, should we be satisfied with doing it this way or should we be
> trying to add the sanity check of velocity numbers? That is the real
> question.

It seems that you're not satisfied. What is triggering that?

Do you break down the work into stories? How long does a typical story
take to be implemented? Also, how long are your sprints and how many
stories (typical range) are accomplished each sprint?

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Dan Rawsthorne]

I've been teaching it for years, and call it "agreement-based planning" There's a chapter about it in my book

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

Let me give some more detail. Basically, the PO and Team work together, one story at a time. The PO puts a story up, they all agree on what it means, task it out (if necessary) and agree that it fits. Then they move to the next story and continue, each time agreeing that all of them fit. Along the way they can take all the possible realities they know into account: look in code at technical debt, who is in the room, dependencies, and so on. They can decide that the Backlog needs to be reordered, they can decide that there can be no more stories of a given type, so the PO needs to move some stories down (for example, if the team has a limited capability for SQL, they can decide that their SQL capacity is full, and so on. I call it agreement-based planning, since the team is agreeing that each story will fit until the sprint is full. The size of the stories is irrelevant to this method of planning; what counts is the acceptance criteria and definition of done as the move along. It has several advantages: 1. it takes into account the realities of the moment 2. it is (in itself) an agile process 3. there is minimal waste (excess inventory of agreed-to stories) when the team is done 4. it gives the best possible answer that the team is capable of.

Just sayin'...  Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

I don't think that Velocity numbers can be trusted for planning. There is too much variability unless the team is trying to hit their numbers - and trying to do this ften leads to gold-plating and/or creation of technical debt. For reasonably complex work, if the team's velocity of (same size) stories is 10 stories per sprint, the inherent variability due to technical debt, people, organization noise, and the rest, means that the Team will likely do between 7 and 13 stories... there is some simple statistical analyses of this in one my appendices...  Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
Author of Exploring Scrum: the Fundamentals

[Aspen R]

Dan,

What you said above about agreement-based planning is 100% what we
do! I like it and it works most of the time ... until we have a
sprint where we over-commit to each other. But the Team usually
learns from the experience and naturally corrects in the next sprint,
so I will take your advice and squash my urge to micromanage them via
velocity numbers. (Repeat to myself: the Team is self managing! The
Team is self managing!)

Yet I still desire historical velocity numbers. The only really good
reason for this, or so I hear, is for release planning. With an
average velocity, I can hopefully answer the age-old question of "when
can we ship it?" If there is a better way or a way to do agreement-
based release planning, I'd love to know more.

-Aspen

[Aspen R]

George,

> Do you break down the work into stories? How long does a typical story
> take to be implemented? Also, how long are your sprints and how many
> stories (typical range) are accomplished each sprint?

Yes, we break it into stories, and we accomplish them within two week
sprints. As for how many stories we usually accomplish, I'm not sure,
and hence my desire to start tracking velocity and other information
about how many stories we can accomplish on average.

-Aspen

[RonJeffries]

Hi Aspen,

On Feb 5, 2012, at 2:36 AM, Aspen R wrote:

Yet I still desire historical velocity numbers.  The only really good
reason for this, or so I hear, is for release planning.  With an
average velocity, I can hopefully answer the age-old question of "when
can we ship it?"  

In my opinion, if you do this, you will likely be making a mistake. Velocity is not stable enough to use this way. It is stable enough to give an indication, and that is all. Worse, focus on velocity to decide when to ship is, well, how can I put this ... it is a mistake.

I do not recall whether you are the Product Owner. I'm assuming that you are not. Either way ... the Product Owner is solely responsible for shipping the best possible product on time. Let me break that down.

The 

• Product Owner (not the team, not the SM) is 
• solely (not jointly with the team, the SM, some project manager ...) 
• responsible for shipping
• the best possible product
• on time (that is, on the desired date)

There is only one way to do this. It goes like this: 

• Do the most valuable backlog items first.
• Produce a truly shippable increment of software in every Sprint.
• Repeat until the due date.
• Ship

If there is a better way or a way to do agreement-
based release planning, I'd love to know more.

Brian @Marick (well worth following on Twitter, even more than I am) blogged this yesterday about two-phase release planning. Responding to a Twitter chat about how to do a truly fixed-content release, he said:

"I like the approach Jeff Patton took at Tomax. My thumbnail version:

1. Promise fixed feature set.
2. Suggest intermediate releases.
3. Surprise them by not whining when they change requirements. Instead, let them slot new requirements into early releases, so long as they shift an equal number into the later one ...
4. thereby build trust, and ...
5. end up in a situation where everyone realizes that the best release is more important than the long-forgotten fixed scope.

"The two important things: fixed scope is a consequence of lack of trust, but trust can be earned, and: their early idea that they had fixed scope was an *illusion*. They'll cling to it because they don't want to have been wrong.

"Your job: let them choose better scope while allowing them to save face and not admit they were deluded about their own knowledge."

The above, and the links contained, are among the best material ever written on this subject. Heed it, that's my advice. 

Ron Jeffries

www.XProgramming.com

I'm really pissed off by what people are passing off as "agile" these days.

You may have a red car, but that does not make it a Ferrari.

  -- Steve Hayes

[Dan Rawsthorne]

Using the actual velocity numbers is probably good enough. If your team is changing sizes or doing something else a little strange, you may need a different productivity measure, like  (hours/SP). Or you could go all-out and use Earned Value metrics like CPI and SPI - not for the faint-hearted.

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

Ron, I go even further than you do. I don't say the PO is responsible for the date, only to deliver the most valuable product he/she can. Then it is up to the Project Manager (the non-scrum guy outside the team) to balance the cost/scope/schedule based on the realities of the velocity coming out of the team

In other words, I don't want the PO to have the PM pressure coming from inside himself. Kind of like separating the PO and SM, I also want to separate the PO and PM. Keep your focus, keep a single focus, etc...

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

What you are describing here, Julie, is the original intent of scrum. Give the team some goals, and let them work it out. It's gotten a lot more prescriptive, largely because XP drives the team with user stories, and scrum seemed like a good fit. they're both scrum...

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
Author of Exploring Scrum: the Fundamentals

[RonJeffries]

Hi Dan,

On Feb 5, 2012, at 9:57 AM, Dan Rawsthorne wrote:

Ron, I go even further than you do. I don't say the PO is responsible for the date, only to deliver the most valuable product he/she can. Then it is up to the Project Manager (the non-scrum guy outside the team) to balance the cost/scope/schedule based on the realities of the velocity coming out of the team

In other words, I don't want the PO to have the PM pressure coming from inside himself. Kind of like separating the PO and SM, I also want to separate the PO and PM. Keep your focus, keep a single focus, etc...

Could be good ideas. But not Scrum as currently defined ...

[Dan Rawsthorne]

But not 'not scrum', either. Scrum only worries about what happens inside the Team and on the boundary, so this is good guidance for most Teams. Nothing more (from Scrum's perspective) than listening to your Stakeholders, IMHO. Gonna be one of the major pieces of guidance in the next "Exploring Scrum" book - separate Product Management from Project Management.  Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
Author of Exploring Scrum: the Fundamentals

[George Dinwiddie]

Aspen,

Don't you have data on how many stories you accomplished each sprint?

[RonJeffries]

On Feb 5, 2012, at 12:44 PM, Dan Rawsthorne wrote:

But not 'not scrum', either. Scrum only worries about what happens inside the Team and on the boundary, so this is good guidance for most Teams.

I think I disagree. "Most" teams do not need a Project Manager, IMO, and I would guess that I'm not the only one.

If you were writing "how to survive in an organization with PMs in it", I might go along with what you're saying. But there's no reason I can see to set up another, separate, axis of concern.

Nothing more (from Scrum's perspective) than listening to your Stakeholders, IMHO.

A PM is not a stakeholder. It is a mechanism for addressing the needs of stakeholders. As such it is at least somewhat, and I think substantially, overlapping with the existing Scrum roles.

Gonna be one of the major pieces of guidance in the next "Exploring Scrum" book - separate Product Management from Project Management.  Dan  ;-) 

I'm sure it'll be good. I suspect it will be "not-Scrum".

Ron Jeffries

www.XProgramming.com

If it is more than you need, it is waste. -- Andy Seidl

[Stuart Turner]

Hi Dan

Why do you think a project manager is required? It seems your
definition of product owner is lacking some responsibilities. Having a
project manager will also mean the team cannot be self managing as
that responsibility is taken by the project manager.

Are you trying to merge one or more methodologies and frameworks into
your own, hopefully unique, one that you can then promote in your
books? If so, I wish you well, but please do not try to pass this off
as Scrum.

Stuart

[Wouter Lagerweij]

The team is (always) supposed to decide how much work they will take into the sprint. 

Historical velocity can be useful data for the team to take into consideration when deciding this, but it's not the only thing that matters for that.

The scope of a sprint is small enough that a team, especially an experienced team, can easiliy determine how much work to take into the sprint. Taking into account other things, like planned releases, planned absences, the weather, uncertainty about certain stories, and all kinds of things that don't let themselves be easily captured in numbers.

As a rule, if your velocity is too stable ("We do 30 points *every* sprint"), then something is wrong. Either your not trying hard enough, or you're simply gaming the numbers.

Wouter

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

--
Wouter Lagerweij         | wou...@lagerweij.com

http://www.lagerweij.com | @wouterla

[Dan Rawsthorne]

The Project Manager I'm talking about probably  isn't on the Scrum Team. If the PM is on the Team it must be the PO and he/she must play by the rules of scrum. It's a layering of agility. First the Team, then the PO, then the PM, then the Portfolio Manager, then the ... up to the top of the stack, which might be the CEO, I'm not sure. 

Project Management teams often use scrum to manage projects, and Portfolio Managers often use scrum to manage portfolios. I will write about using scrum for project management, but (of course), it is using scrum, not scrum. Scrum is a small set of tools in your toolbox. They are almost universally useful, but almost never sufficient. Even for software development we need technical tools that aren't part of scrum. Scrum is all about producing valuable results at a sustainable pace, nomatter what the results may be.

Thanks,  Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST

www.3Back.com

Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

Of course Teams don't need project managers, Projects do - at least in many organizations. Scrum is about Teams producing valuable Results at a sustainable pace; Projects are about Scope, Cost and Schedule (and other things). POs manage Scope on Scrum teams, Project Managers balance Scope, Cost and Schedule on Projects. Two different issues, two different domains, two different roles. If the PO is managing Cost and Schedule as well as Scope, then the PO is playing the PM role, and using Scrum's rules to do so. If the Project Manager is outside the Scrum Team (which I usually recommend) then things get interesting, since the PM must interact with the Scrum Team by Scrum's rules. What this does to the PM role is one of the things I am exploring.

Another thing I am exploring is the separation of concerns this causes. PO's manage Scope, PM's balance Scope, Cost, and Schedule based on the reality of the Scrum Team's ability to produce Scope... it's a very agile thing we are requiring of the PM, and very interesting. I have found that when PO's have PM responsibilities the PO often gets too caught up in Cost and Schedule issues - and this causes harm. I think we agree with this. So, this is why I suggest separating the concerns; it's mostly a Scrum Values thing - try to have a single focus.

Anyway, I think that we're mostly in violent agreement about Scrum Teams whose Results are working software. We may not agree that Project Management or Portfolio Management is a Result that can be produced by a (management, not development) Scrum Team, but it is one of the things I am exploring (and implementing in some cases). I'm finding it very cool and useful, and will write about it soon.

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST

www.3Back.com

Author of Exploring Scrum: the Fundamentals

On 2/8/2012 5:24 AM, Stuart Turner wrote:

[Nigel Baker]

WRONG!

No PM's in Scrum. You know better than that, Dan. Sitting someone
outside the team taking ownership of half of the PO's job and half of
the SM's is awful.

PO can own all that Budget stuff. And should. Else they are a mere
Super User or BA.

And I pity the fool who takes that role on.

Nigel


On Feb 5, 5:44 pm, Dan Rawsthorne <dan.rawstho...@drdansplace.com>
wrote:

> But not 'not scrum', either. Scrum only worries about what happens
> inside the Team and on the boundary, so this is good guidance for most
> Teams. Nothing more (from Scrum's perspective) than listening to your
> Stakeholders, IMHO. Gonna be one of the major pieces of guidance in the
> next "Exploring Scrum" book - separate Product Management from Project
> Management.  Dan  ;-)
>
> Dan Rawsthorne, PhD, PMP, CST

> Author of /Exploring Scrum: the Fundamentals/
> <http://www.amazon.com/dp/1461160286>

>
> On 2/5/2012 8:52 AM, RonJeffries wrote:
>
>
>
>
>
>
>
> > Hi Dan,
>
> > On Feb 5, 2012, at 9:57 AM, Dan Rawsthorne wrote:
>
> >> Ron, I go even further than you do. I don't say the PO is responsible
> >> for the date, only to deliver the most valuable product he/she can.
> >> Then it is up to the Project Manager (the non-scrum guy outside the
> >> team) to balance the cost/scope/schedule based on the realities of
> >> the velocity coming out of the team
>
> >> In other words, I don't want the PO to have the PM pressure coming
> >> from inside himself. Kind of like separating the PO and SM, I also
> >> want to separate the PO and PM. Keep your focus, keep a single focus,
> >> etc...
>
> > Could be good ideas. But not Scrum as currently defined ...
>
> > Ron Jeffries

> >www.XProgramming.com<http://www.xprogramming.com>