Standardizing Story Points across the enterprise

[Guarino]

We have approx 15 development teams, some using Kanban, some using Scrum.

Recently we have tried to implement a monthly "Dev Ops" meeting, where teams have approx 5-10 mins to update everyone what is going on.  What projects, what they learned from retros, stating impediments and how they were addressed.

One of the things we show in this meeting is a team wide, then location wide cycle time report.

Since this meeting is a coming together of dev, some managers, some product managers, etc, the concepts of story points and burndowns can be a bit burdensome, so that is why we went with cycle time.

So now, glaringly, the differences in team points has floated to the top of something we "might" want to address.

I am not sure what to ask, so bare with me a bit.  Is there merit in getting all the teams to agree what a 5pt story is?  How do you go about this without saying, "A 5pt story is like 2-3 days".  Most of the conversations end up at this point, and get days assigned to points.  I am trying to stay clear of that, but it seems impossible.

We discussed tshirt sizes, each team would agree that a medium shirt is the "typical" story for that team.  Does that have any merit, never defining how long or how many "story points" the shirt size is worth.

I guess I am looking for ideas, thoughts why it would be good and bad, any information that would help me bring these thoughts to conclusion.  The "business" is skeptical that one teams 13 points is 4 days and another teams is 2 weeks.  Is there anywhere that common ground can be found?  Anyone tackle this sort of thing with success?

Again, this is more of a brainstorming, nobody is mandating it, but does seem in the best interest to find a way that teams can be transparent without showing a burndown chart.

Ideas?

Thanks

[Alan Dayley]

"Recently we have tried to implement a monthly "Dev Ops" meeting, where teams have approx 5-10 mins to update everyone what is going on.  What projects, what they learned from retros, stating impediments and how they were addressed."

This is very good! Knowledge sharing as a community about problems and solutions is a great thing.

"One of the things we show in this meeting is a team wide, then location wide cycle time report."

This is not so good. You are turning a knowledge sharing meeting into a status meeting.

Quick answer: Standardizing on the meaning of story points across an enterprise and even between just two teams largely destroys the usefulness of story points. Remember all the problems with estimating and reporting in hours or days? They will all come back. Don't do it.

If you decide to do it anyway, just drop the sophistry of "fake story points" and estimate everything in hours or days.

Now, if you will indulge me, I'd like to steer the discussion away from how, to questions of why. What benefit does the organization gain by having a standardized measure across all teams? What problem would this solve?

The only problem I see expressed in your description is that of removing the need to educate managers about story points. That is not a good reason to destroy the value of using story points. What is the real reason or reasons for this standardization desire?

Alan

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

[Juan Pablo Botero]

IMO, i think that is the way your teams are self organized, but the question if the story points are clear to other skateholders, like product owner when they are planning?.

2013/3/28 Alan Dayley <ada...@gmail.com>

--
Cordialmente:
Juan Pablo Botero
Administrador de Sistemas informáticos
Fedora Ambassador for Colombia

http://www.jpilldev.net

[Guarino]

Thanks for your post Alandd,

I feel the cycle time report is a good thing to show across all teams.  It helps discussion of what teams are doing, and helps bring out issues that you may not even know.  Having a room full of people that may have conquered something similar, I think this is a good thing.

At any rate, I am not sure on pros and cons of standardizations, I guess that is why my question/post is so vague.  It feels like the right thing to do, so teams can discuss things on equal ground.  But I agree with you, in fact I even brought that up, that if we try to equate everything, we should go to DAYS, because we all know what a DAY is.

Has anyone done this?  What was the outcome?

There are some suggesting that teams estimate in shirt sizes, and that the points be assigned "in the background".  Cycle times could be created off these sizes.  But, as you pointed out Alandd, to what purpose?

The manager/higher ups want ways of showing that this team is doing well, or maybe this team needs another person.  I actually agree with this, we cant live in agile-land, while the people making important decisions are left trying to figure out why team A can do 100 pts in the same time team B can do 25.

I get the clash here between PM and Scrum, but it is a very real world problem.  I am a big proponent of transparency, but how can we make that more standard?

If we dont standardize story points, do we find some other way to show team statuses?

Thanks again for input, as you can see, I am just throwing stuff against the wall.  I want to find charts or numbers that make sense, don't create bad behaviors and are meaningful...

Seems easy enough :)

[Guarino]

Maybe I can ask it this way, what charts and metrics do people show to their higher up folks?

[Ron Jeffries]

Guarino,

On Mar 28, 2013, at 3:00 PM, Guarino <sofa.k...@gmail.com> wrote:

I am not sure what to ask, so bare with me a bit.  Is there merit in getting all the teams to agree what a 5pt story is?  How do you go about this without saying, "A 5pt story is like 2-3 days".  Most of the conversations end up at this point, and get days assigned to points.  I am trying to stay clear of that, but it seems impossible.

There is nothing at all good that can come of trying to standardize your points. There is nothing at all good that can come from trying to compare your teams.

Even comparing cycle time is nearly useless. Cycle time is a function of team makeup, and team capability, yes. It is also more than anything else, a function of the absolute "size" of the story, which is entirely arbitrary and up to your product owners, not to the team.

We do Scrum to look for impediments. We do Kanban to look for impediments. 

Management should focus their attention on the value of the things being done. The teams should focus their attention on smoothing the flow of getting things done. 

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?

[Rafael Sabbagh]

Alan,

+1 on all you said. Very good.


Best regards,

Rafael Sabbagh
Agile Trainer & Coach
Certified Scrum Trainer (CST)
________________________
Sabbagh Training & Coaching
Rio de Janeiro - Brazil
+55 (21) 9999-7895
http://rsabbagh.com
http://facebook.com/SabbaghTC
@rsabbagh

[Dan Rawsthorne]

Well, Guarino, it's not impossible. But is it useful? Why do you want to do it?

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Kurt Häusler]

On 28 Mar 2013, at 20:00, Guarino <sofa.k...@gmail.com> wrote:

>
>
> I am not sure what to ask, so bare with me a bit. Is there merit in getting all the teams to agree what a 5pt story is?

No.

[Dan Rawsthorne]

Merit to whom? To the teams? No. To an external Project Manager? Maybe. What problem are you trying to solve. Or is this a solution looking for a problem?

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Kurt Häusler]

On 28 Mar 2013, at 20:57, Ron Jeffries <ronje...@acm.org> wrote:
>
> Even comparing cycle time is nearly useless. Cycle time is a function of team makeup, and team capability, yes. It is also more than anything else, a function of the absolute "size" of the story, which is entirely arbitrary and up to your product owners, not to the team.

I always understood (average) cycle time to be dependant on the process, in the case of a Scrum team they can correlate quite strongly with sprint lengths. Or perhaps across a wider process they might be based mostly on the release cadence. Throughput seems to be the value most affected by team makeup. I was surprised by the lower than expected correlation between item size and cycle time.

[Ron Jeffries]

Hi Dan

On Mar 28, 2013, at 8:13 PM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Merit to whom? To the teams? No. To an external Project Manager? Maybe. What problem are you trying to solve. Or is this a solution looking for a problem?

Could you please do a brief description of what good an external PM could do with consistently-sized story points, including how they would avoid doing all the obviously bad things. 

Thanks,

Ron Jeffries

www.XProgramming.com

It's true hard work never killed anybody, but I figure, why take the chance?

-- Ronald Reagan

[Dan Rawsthorne]

Well, first of all, you need a PM that doesn't do all the obviously wrong things. Then, the SPs are used as input to changing baseline assumptions and balancing project plans. They are one of the major visibility points into the development...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Ron Jeffries]

Hi Dan,

On Mar 28, 2013, at 8:53 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

Well, first of all, you need a PM that doesn't do all the obviously wrong things. Then, the SPs are used as input to changing baseline assumptions and balancing project plans. They are one of the major visibility points into the development...

OK, so first select a PM from the null set.

Then please say more about what changing baseline assumptions and balancing project plans means, and how they do it.

Here's one example: 

I suppose balancing project plans means observing, now that all the stories are the same size, that team A is overloaded and team B is not. So we move some stories from A to B?

Voila! If we do, we discover that the stories are no longer the same size because team A knew how to do them and team B did not.

Or we move people from B to A?

Voila! Both teams immediately slow down, A more than B …

Really. I seriously question whether there is anything even a good PM could do using balanced story sizes better than he could do without balanced story sizes. My guess is Not One Thing.

Ron Jeffries

www.XProgramming.com

You never know what is enough unless you know what is more than enough. -- William Blake

[Dan Rawsthorne]

no. balancing a plan means that cost, scope, and schedule are in balance based on the realities of development. Keeping project plans in balance is the main job of a project manager, according to the PMI. It's all about the plan.

Examples of Assumptions (original baselines):
�- this Project is worth XX� StoryPoints (this requires SPs that are about size, not effort)
�- a StoryPoint will take HH Hours on average
�- an Hour will cost DD Dollars on average

Then, the Project Plan is based on these assumptions. The assumptions are constantly monitored and re-baselined, thus changing the plans. Doing this chore is the main job of the Project Manager during the execution of the Project... their tools are changing scope, changing budget, and so on. Oh, and they also explain to Project Stakeholders why they aren't getting what they want, etc... the PM is the Product Owner of the Project Plan.

A PM in a scrum environment has no need to manage the team members - that's taken care of already. they should stay in their own rice bowl.

I don't understand what you could possibly mean by a team being overloaded or not. A team does what it does - it gets to Done while working at a Sustainable Pace.

BTW, I'm really sorry you've never seen a good Project Manager :(

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

On 3/28/2013 5:59 PM, Ron Jeffries wrote:

Hi Dan,

On Mar 28, 2013, at 8:53 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

Well, first of all, you need a PM that doesn't do all the obviously wrong things. Then, the SPs are used as input to changing baseline assumptions and balancing project plans. They are one of the major visibility points into the development...

OK, so first select a PM from the null set.

Then please say more about what changing baseline assumptions and balancing project plans means, and how they do it.

Here's one example:�

I suppose balancing project plans means observing, now that all the stories are the same size, that team A is overloaded and team B is not. So we move some stories from A to B?

Voila! If we do, we discover that the stories are no longer the same size because team A knew how to do them and team B did not.

Or we move people from B to A?

Voila! Both teams immediately slow down, A more than B �

Really. I seriously question whether there is anything even a good PM could do using balanced story sizes better than he could do without balanced story sizes. My guess is Not One Thing.

Ron Jeffries

www.XProgramming.com

You never know what is enough unless you know what is more than enough. -- William Blake

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

�
�

[Ron Jeffries]

Hi Dan,

On Mar 28, 2013, at 9:40 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

no. balancing a plan means that cost, scope, and schedule are in balance based on the realities of development. Keeping project plans in balance is the main job of a project manager, according to the PMI. It's all about the plan. 

Examples of Assumptions (original baselines):

 - this Project is worth XX  StoryPoints (this requires SPs that are about size, not effort)

 - a StoryPoint will take HH Hours on average

 - an Hour will cost DD Dollars on average

None of this requires story points to be equal across teams. Each team has its backlog and its velocity. That suffices to allow the PM to roll up to hours and dollars. No PM on earth walks in walking story points.

Then, the Project Plan is based on these assumptions. The assumptions are constantly monitored and re-baselined, thus changing the plans. Doing this chore is the main job of the Project Manager during the execution of the Project... their tools are changing scope, changing budget, and so on. Oh, and they also explain to Project Stakeholders why they aren't getting what they want, etc... the PM is the Product Owner of the Project Plan.

Yes. Of course changing the plan is actually the job of the PO not the PM so this is inherently screwy. Of course Scrum doesn't even HAVE a PM role, and it looks like a pretty good way to be to me.

A PM in a scrum environment has no need to manage the team members - that's taken care of already. they should stay in their own rice bowl.

Yes. And no need to have their story points line up either. Did I mention that Scrum does not specify story points and that the person who invented them thinks they are a bad idea?

I don't understand what you could possibly mean by a team being overloaded or not. A team does what it does - it gets to Done while working at a Sustainable Pace.

Overloaded in this context means producing stuff slower than we need in order to synchronize or deliver by desired date.

BTW, I'm really sorry you've never seen a good Project Manager :(

I've never seen a purple cow, either.

[Dan Rawsthorne]

The size of the Project is independent of Teams. The cost of the Project is Team dependent. The three assumptions I gave are independent, and they need to be in order to manage the project effectively. All standard Project Management, btw, even though most people calling themselves project managers don't have a clue. Pity... we can hope all they need is education. I guess if we can believe we can turn Teams into scrum teams, we should be able to believe we can turn project managers into proper project managers. Respect...

The PO could be the PM, but that's probably a bad idea, for all the reasons you think it would be. Of course, in a single team project, the Team's PO may also be the Project's PM, but I strongly recommend against it, for basically the same sort of reasons we strongly recommend the PO not be the SM.

One of the reasons I'm so happy about the AgileAtlas as it stands is that it shows that Scrum is not about Projects - there are no Scrum ceremonies to start and stop, and starts and stops are what define projects. We finally got it right, the PO is managing flow, producing value sprint to sprint. This is NOT Project Management. In the Scrum context, the PM needs to keep modifying the backlog and/or timeline to make them match up - this is balancing the plan.

And, many PMs walk in talking Function Points, etc... You can't manage with dollars, you need to manage with size. that's the issue here... when I'm done, I hope many PMs will be talking StoryPoints, and in a way that is helpful to Scrum Teams, not harmful :)

Yes, StoryPoints are a bad idea if you're trying to use them to manage a Scrum Team. They don't do a good job of helping a Team figure out how much will fit in a Sprint, as most of us now realize. The only real, valid, reason for StoryPoints is that they help us get a Velocity, which can help us estimate release dates an so on.

In fact, Ken has gone so far as to define velocity as #features/$100K, which is clearly useful for PMs, but very hard to measure or estimate, as the size of features varies all over the place. So, by letting SPs bethe size units we use to measure features, and assuming a fixed team size, then Velocity = #SPs/Sprint achieves the same goal.

In other words, StoryPoints are a very good way for managing a Project, but only when they represent size, not effort. In other words, Size(Story) is a function of Story, just as the word suggests. Just like UseCasePoints, FeaturePoints, FunctionPoints, etc. I loved your definition of StoryPoint as a relative measure of difficulty, as that's not time or effort. I like Cohn's definition as a relative measure of size, and then admitting that this could mean different things to different Teams. I love the 'pile of rocks' metaphor for StoryPoints. All good. I don't know when, or how, it turned into relative measure of effort/time - I guess because it's easier for teams to do...

I still don't know what you mean by overloaded. Do you mean "slower than I want you to be?" That's what it sounds like. Or do you mean that the Team's Backlog is too big? I really don't understand what you're getting at. Probably you mean "The Team has too much stuff to finish by the due date" in which case I say "Yes, so we must change the due date or the Backlog" - this is plan balancing, the PM's job.

Anyway, I'm working on this stuff... almost good to go with the SP stuff.  Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Ron Jeffries]

Dan …

On Mar 29, 2013, at 11:46 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

The size of the Project is independent of Teams. The cost of the Project is Team dependent. 

What are the units of "size"? 

Ron Jeffries

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

[Michael Vizdos]

[getting a bag of popcorn for this the Dan and Ron show on this topic...]

Overall though... um... DO NOT compare points between teams.

Maybe do the "5 Whys" to see what people really need out of what they are asking.

Nothing good will come out of standardizing a story point.

Pick a date.  Pick a budget to fund the team(s) to that date.  Prioritize the scope (sorry... it's ALL not a priority one -- if it is perceived as the "real world" case then there is a different conversation altogether).

Thank you.

- mike vizdos
   www.michaelvizdos.com/contact

[Dan Rawsthorne]

Use Cases, Function Points, features, etc. How much stuff is being built. The units used are varied and often process dependent. In my world they are the things that StoryPoints are a relative measure of. They are hard to get at...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

On 3/29/2013 10:43 AM, Ron Jeffries wrote:

Dan �

On Mar 29, 2013, at 11:46 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

The size of the Project is independent of Teams. The cost of the Project is Team dependent.�

What are the units of "size"?�

Ron Jeffries

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

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

�
�

[Michael James]

On Mar 29, 2013, at 11:50 AM, Michael Vizdos <mvi...@gmail.com> wrote:

[getting a bag of popcorn for this the Dan and Ron show on this topic...]

You didn't TiVo any of the last five episodes?

--mj

(Michael)

[John Clifford]

I have to disagree with those who argue against standardizing of story points. This is something I strongly encourage my many clients running multiple teams on large projects to do, because it greatly eases the ability to forecast. We also use the full Fibonacci series (not a hybrid, or abbreviated, or truncated, or munged version) because this allows us to stop worring about precision and focus on accurate estimates... and accurate estimates are the only estimates that matter.

If a representative subgroup from across the project get together and estimate relative sizes using story points, then that is as good a way as any to estimate and better than most. Remember, story points AREN'T a measure of time, they are a measure of effort. They are also NOT a measure of uncertainty; we handle uncertainty through velocity.

Let me explain. Each team sets their sprint commitment at sprint planning time, from a prioritized list of backlog items given by the Product Owner (the team has worked in grooming sessions with the PO prior to planning, to understand and clarify story acceptance criteria, etc., and moves groomed items to 'ready-ready' status... but no re-estimating). Each team uses its demonstrated velocity (3-sprint m/a, velocity from the last sprint) as guidance on how much to commit, but the team decides based upon the combination of stories. In other words, teams with an average velocity of 50 points don't commit to 50 points, they commit to as many stories as they truly believe they can accomplish in the sprint, and let the total # of points be what it is. If some stories are more uncertain than others, the team may commit to less stories/items to account for the uncertainty... and that shows up as decreased velocity as it should. Uncertainty is friction that lowers velocity.

So, as long as the relative estimates are accurate (generally plus/minus one Fibonacci 'step', e.g., a '21' means the item is somewhere between 13 and 34 story points in effort), then the number itself doesn't matter. By the way, we don't reward or punish teams based upon their velocity as it compares to other teams. Velocity is a measure of productivity, but it's a relative measure, more like a golf handicap than an actual score... and the goal is not to beat the other teams, it is to improve your game to the best level that you can play with given your constraints (team size, skill levels, mix of talents and abilities). 

For more information on Agile estimation techniques, see my webinar at http://www.construx.com/Resources/Webinar/Webinar__Agile_Estimation__Key_Principles_and_Practices.

[Michael Vizdos]

... must still be on my TiVo.  It's still all good learning into how many angels can fit onto the pin of a head (or something like that)...

[now back to our regularly scheduled thread]

Thank you.

- mike vizdos
   www.michaelvizdos.com/contact

[Ron Jeffries]

Dan,

On Mar 29, 2013, at 3:25 PM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Use Cases, Function Points, features, etc. How much stuff is being built. The units used are varied and often process dependent. In my world they are the things that StoryPoints are a relative measure of. They are hard to get at...

Use cases are not constant sized, nor sized at all. Seems unlikely that two projects each with 500 use cases are anything like the same "size".

Function points were intended to serve as size, but as I read the literature, no two projects estimate FP similarly.

Features, come on, get real. Completely random in size.

Size in square meters and square feet are different numbers but the same size.

You keep saying that size is important. If it doesn't have units and is not comparable … what is it?

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

[Michael Vizdos]

Yep... the rationalization sounds good -- and it sounds like you know what you are doing and what works and what does not for you.

I've hashed on this topic a bit too over the years at: http://www.implementingscrum.com/?s=story+points

Really though.

Prioritize.  Deliver.

The conversations change.

Thank you.

- mike vizdos
   www.michaelvizdos.com/contact

[Dan Rawsthorne]

Do you know a big dog when you see it? What makes it a big dog? Height? Weight? Fierceness? Appetite? Size is in the eye of the beholder, but we all tend to agree on what is small, medium, or large.

So what is size for a functional story. It's something we estimate with relative sizes... that's the whole point. Everybody sees size differently. Some see how many widgets were added, some see moving parts in the code. some see methods and properties. some see states. So, we have a estimation game and all agree if something is Small, Medium, or Large. Why do you think we're estimating it in the first place? Because it's HARD to define, and it's HARD to measure.

That's why a like the pile of rocks metaphor. What do you measure? number of rocks? cubic feet of rocks, tonnage of rocks. I don't know, and I don't care. But when I"m comparing one pile of rocks to another, I can tell which is larger - and most of us will be pretty consistent on that.

What kind of size is important to you? we know that since we've added functionality (a new test passes), that we've made the system larger larger. How much larger? One test's worth... maybe that's good enough. Ken now defines Velocity as #Features/$100K. Does this make sense? Sure, once everybody agrees on what it means.

Now, this thread started with the question of standardizing the estimations. That's a different issue. Once we figure out what size is, then we can worry about normalizing it so that it can be added and compared. One step at a time.

Dan� ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

On 3/29/2013 12:34 PM, Ron Jeffries wrote:

Dan,

On Mar 29, 2013, at 3:25 PM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Use Cases, Function Points, features, etc. How much stuff is being built. The units used are varied and often process dependent. In my world they are the things that StoryPoints are a relative measure of. They are hard to get at...

Use cases are not constant sized, nor sized at all. Seems unlikely that two projects each with 500 use cases are anything like the same "size".

Function points were intended to serve as size, but as I read the literature, no two projects estimate FP similarly.

Features, come on, get real. Completely random in size.

Size in square meters and square feet are different numbers but the same size.

You keep saying that size is important. If it doesn't have units and is not comparable � what is it?

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]

By the way, John, I disagree. The Team does NOT set a commitment at planning time. At best they forecast what might happen. Their commitment is to getting things done, not to a quantity of things. The sizing is not useful to the team, it not used to put pressure on a team, it is only used so that a PM can know what's going on so that the plans can be updated appropriately based on the realities of the moment.

Project Management is NOT a coercive activity in a scrum environment. Scrum forbids that. It is a process of observing, measuring, and adapting plans to reality.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Ron Jeffries]

Dan,

On Mar 30, 2013, at 1:26 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

So what is size for a functional story. It's something we estimate with relative sizes... that's the whole point. Everybody sees size differently. Some see how many widgets were added, some see moving parts in the code. some see methods and properties. some see states. So, we have a estimation game and all agree if something is Small, Medium, or Large. Why do you think we're estimating it in the first place? Because it's HARD to define, and it's HARD to measure.

I believe this conversation began because someone wanted to normalize story estimates. That tells me that they want to compare story estimates. They probably want to "improve" them as well. Both of these ideas are sharp on all their edges and cut almost everyone who handles them.

You also suggest that this one good PM that you know wants to add them up. That would be more compelling, except that the good PM, if in fact she is not just some fantasy in your mind, is already a good PM and has presumably only recently encountered story points, and so she already knows how to add things up to see how things are going. She should keep doing that however she does it.

I believe that we agree that backlog items are expressed in terms of what the PO (and therefore the PM) want to get done. We also know that the backlog items accomplished are all of a size that can get done in one Sprint, since we can't do anything that takes more than one Sprint.

And, if we are working toward getting some project done, then I think we can anticipate that the PM has a big list of all the things that will need to be done, and knows which team is going to do them. And, observing the teams, she knows the cycle time of each team and therefore has a perfectly good measure of how things are going already. 

I conclude that if in fact there is a good PM, she already has in hand everything she needs to know where we are and how we're doing, and that trying to normalize story points would be muda. 

This is especially the case because of the sharp edges on story point normalization and comparison. The OP's group, it seemed to me, wanted to normalize story points so that they could compare the teams. Comparing teams is bad. It is counter to Scrum's principles. Teams are self organizing. They improve their own performance: they do not have improvement goals imposed upon them.

It is almost impossible for an organization to benefit from normalizing and comparing story points. It is focus on the wrong end of the stick. The right end of the stick, the thing to think about, is value. 

The odds are that normalizing and comparing story points will bring about a poor situation and will not lead to better use of Agile. I can imagine being in a specific situation where normalizing and comparing story points would be something I would recommend. I have never been in such a situation in the seventeen years I've been doing Agile, nor in the half-century I've been doing software. 

Thus in a group like this one, with many listeners, I strongly advise against normalizing and comparing story points across teams.

Ron Jeffries

www.XProgramming.com

Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

[Wouter Lagerweij]

Hi Guarino,

Lots of great discussion here, so you probably already have more than enough advice. But I can't resist:-)

The most important question is of course: why do you need this data? 

Your answer to that above is that management wants to know when to jump in and change team composition. 

The agile way of dealing with that is to wait until the team asks for a change. In Scrum that would be raised in retrospectives. In a Kanban team, I'd expect a bottleneck to have shown up on the board, and after careful root cause analysis the conclusion was that there really is an unbalance in the team composition and we really need that extra tester. At that point, a line manager or coach might challenge the team to see if there is any other way to deal with this (work TDD, so there's fewer issues, build more test-automation tooling, etc.) before actually giving in to such a request.

Another remark was that 'business' is skeptical about the fact that points mean different things to different teams. 

That would mean that they are not very much involved with the teams and the project(s?), and feel that the teams are 'cheating'. It would be good to find out why they think that.

If one really wanted, the figures are already there: simply calculate the 'value' in time for storypoints using the cycle time figures you have. Of course, that would still not mean anything useful, but it would show that storypoints are different per team. 

On the Kanban side again, statistical analysis of cycle times for all stories might give you a few different clusters of story-size, expressed in cycle time, along with their deviations. That would be a possible starting point for your t-shirt size estimates. Those can have different SLAs / swimming lanes on your Kanban boards. This won't change anything in how quickly work gets done, but can be used to manage some expectations.

Wouter

On Thu, Mar 28, 2013 at 8:00 PM, Guarino <sofa.k...@gmail.com> wrote:

We have approx 15 development teams, some using Kanban, some using Scrum.

Recently we have tried to implement a monthly "Dev Ops" meeting, where teams have approx 5-10 mins to update everyone what is going on.  What projects, what they learned from retros, stating impediments and how they were addressed.

One of the things we show in this meeting is a team wide, then location wide cycle time report.

Since this meeting is a coming together of dev, some managers, some product managers, etc, the concepts of story points and burndowns can be a bit burdensome, so that is why we went with cycle time.

So now, glaringly, the differences in team points has floated to the top of something we "might" want to address.

I am not sure what to ask, so bare with me a bit.  Is there merit in getting all the teams to agree what a 5pt story is?  How do you go about this without saying, "A 5pt story is like 2-3 days".  Most of the conversations end up at this point, and get days assigned to points.  I am trying to stay clear of that, but it seems impossible.

We discussed tshirt sizes, each team would agree that a medium shirt is the "typical" story for that team.  Does that have any merit, never defining how long or how many "story points" the shirt size is worth.

I guess I am looking for ideas, thoughts why it would be good and bad, any information that would help me bring these thoughts to conclusion.  The "business" is skeptical that one teams 13 points is 4 days and another teams is 2 weeks.  Is there anywhere that common ground can be found?  Anyone tackle this sort of thing with success?

Again, this is more of a brainstorming, nobody is mandating it, but does seem in the best interest to find a way that teams can be transparent without showing a burndown chart.

Ideas?

Thanks

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

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

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

[George Dinwiddie]

Hi, Dan,

On 3/30/13 1:26 AM, Dan Rawsthorne wrote:
> Do you know a big dog when you see it? What makes it a big dog? Height?
> Weight? Fierceness? Appetite? Size is in the eye of the beholder, but we
> all tend to agree on what is small, medium, or large.

You would think we'd agree. I had a friend with a great dane who
considered labrador retrievers "medium" and collies "small."

>
> So what is size for a functional story. It's something we estimate with
> relative sizes... that's the whole point. Everybody sees size
> differently. Some see how many widgets were added, some see moving parts
> in the code. some see methods and properties. some see states. So, we
> have a estimation game and all agree if something is Small, Medium, or
> Large. Why do you think we're estimating it in the first place? Because
> it's HARD to define, and it's HARD to measure.
>
> That's why a like the pile of rocks metaphor. What do you measure?
> number of rocks? cubic feet of rocks, tonnage of rocks. I don't know,
> and I don't care. But when I"m comparing one pile of rocks to another, I
> can tell which is larger - and most of us will be pretty consistent on
> that.

In the software development industry, we've been pretty terrible at
agreeing as to whether a pile of unwritten code is bigger or smaller
than another pile of unwritten code. Those who don't do the work tend to
be worse at judging this. (I suspect I'd be pretty bad as estimating the
rock piles compared to someone who does the work. The characteristics of
the rock pile and the equipment they had might change the judgement.)

That's why I'm in favor of having those that do the work, do the
estimate. When you do that, of course, the hope of correlated estimates
goes right out the window.

The good thing is that it often doesn't matter very much, as long as we
don't start assuming accuracy and adding precision. When we start
calculating based on estimates (rather than, perhaps, the central
tendency of estimates), then we can magnify our problems in a hurry.

- George

>
> What kind of size is important to you? we know that since we've added
> functionality (a new test passes), that we've made the system larger
> larger. How much larger? One test's worth... maybe that's good enough.
> Ken now defines Velocity as #Features/$100K. Does this make sense? Sure,
> once everybody agrees on what it means.
>
> Now, this thread started with the question of standardizing the
> estimations. That's a different issue. Once we figure out what size is,
> then we can worry about normalizing it so that it can be added and
> compared. One step at a time.
>

> Dan ;-)

> Dan Rawsthorne, PhD, PMP, CST

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

> On 3/29/2013 12:34 PM, Ron Jeffries wrote:
>> Dan,
>>
>> On Mar 29, 2013, at 3:25 PM, Dan Rawsthorne
>> <dan.raw...@drdansplace.com

>> <mailto:dan.raw...@drdansplace.com>> wrote:
>>
>>> Use Cases, Function Points, features, etc. How much stuff is being
>>> built. The units used are varied and often process dependent. In my
>>> world they are the things that StoryPoints are a relative measure of.
>>> They are hard to get at...
>>
>> Use cases are not constant sized, nor sized at all. Seems unlikely
>> that two projects each with 500 use cases are anything like the same
>> "size".
>>
>> Function points were intended to serve as size, but as I read the
>> literature, no two projects estimate FP similarly.
>>
>> Features, come on, get real. Completely random in size.
>>
>> Size in square meters and square feet are different numbers but the
>> same size.
>>
>> You keep saying that size is important. If it doesn't have units and

>> is not comparable … what is it?
>>
>> Ron Jeffries
>> www.XProgramming.com <http://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

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

[John Clifford]

Dan, the point (no pun intended) about commitment at sprint planning is to ensure that the team, and only the team, decides on how much work they can reasonably accomplish. Whatever they commit to, it should be done with the firm understanding that it is achievable thru sustainable pace... not as something that someone else insists on and that is unreasonable. You are right in that the sprint commitment is a forecast to the PO and the organization, but it should be taken seriously by the team (not some arbitrary goal that no one cares about or is invested in). Really, the true commitment is that everyone will accomplish as much as they can while adhering to the agreed-upon practices and processes (not shortcutting quality or completeness for expediency), at a sustainable pace.

[John Clifford]

Prioritize, deliver, measure/evaluate, improve. Repeat until....

I can agree with that.

[Dan Rawsthorne]

Actually, George. I don't think the hope of correlated estimates goes out the window. When doing the estimations we often use an examplar - a story we are comparing all the stories to. Maybe we use multiple exemplars, a Small, Medium, and Large. Then, getting consistent estimates across teams is merely a matter of using correlated examplars, and then trusting the teams. Expanding your sense of community, so to speak.

Dan Rawsthorne, PhD, PMP, CST
3Back.com

Author of Exploring Scrum: the Fundamentals

On 3/30/2013 9:04 AM, George Dinwiddie wrote:

Hi, Dan,

On 3/30/13 1:26 AM, Dan Rawsthorne wrote:

Do you know a big dog when you see it? What makes it a big dog? Height?
Weight? Fierceness? Appetite? Size is in the eye of the beholder, but we
all tend to agree on what is small, medium, or large.

You would think we'd agree. I had a friend with a great dane who considered labrador retrievers "medium" and collies "small."

So what is size for a functional story. It's something we estimate with
relative sizes... that's the whole point. Everybody sees size
differently. Some see how many widgets were added, some see moving parts
in the code. some see methods and properties. some see states. So, we
have a estimation game and all agree if something is Small, Medium, or
Large. Why do you think we're estimating it in the first place? Because
it's HARD to define, and it's HARD to measure.

That's why a like the pile of rocks metaphor. What do you measure?
number of rocks? cubic feet of rocks, tonnage of rocks. I don't know,
and I don't care. But when I"m comparing one pile of rocks to another, I
can tell which is larger - and most of us will be pretty consistent on
that.

In the software development industry, we've been pretty terrible at agreeing as to whether a pile of unwritten code is bigger or smaller than another pile of unwritten code. Those who don't do the work tend to be worse at judging this. (I suspect I'd be pretty bad as estimating the rock piles compared to someone who does the work. The characteristics of the rock pile and the equipment they had might change the judgement.)

That's why I'm in favor of having those that do the work, do the estimate. When you do that, of course, the hope of correlated estimates goes right out the window.

The good thing is that it often doesn't matter very much, as long as we don't start assuming accuracy and adding precision. When we start calculating based on estimates (rather than, perhaps, the central tendency of estimates), then we can magnify our problems in a hurry.

�- George

What kind of size is important to you? we know that since we've added
functionality (a new test passes), that we've made the system larger
larger. How much larger? One test's worth... maybe that's good enough.
Ken now defines Velocity as #Features/$100K. Does this make sense? Sure,
once everybody agrees on what it means.

Now, this thread started with the question of standardizing the
estimations. That's a different issue. Once we figure out what size is,
then we can worry about normalizing it so that it can be added and
compared. One step at a time.

Dan� ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com <http://www.3Back.com>
Author of /Exploring Scrum: the Fundamentals/
<http://www.amazon.com/dp/1461160286>
On 3/29/2013 12:34 PM, Ron Jeffries wrote:

Dan,

On Mar 29, 2013, at 3:25 PM, Dan Rawsthorne
<dan.raw...@drdansplace.com
<mailto:dan.raw...@drdansplace.com>> wrote:

Use Cases, Function Points, features, etc. How much stuff is being
built. The units used are varied and often process dependent. In my
world they are the things that StoryPoints are a relative measure of.
They are hard to get at...

Use cases are not constant sized, nor sized at all. Seems unlikely
that two projects each with 500 use cases are anything like the same
"size".

Function points were intended to serve as size, but as I read the
literature, no two projects estimate FP similarly.

Features, come on, get real. Completely random in size.

Size in square meters and square feet are different numbers but the
same size.

You keep saying that size is important. If it doesn't have units and

is not comparable � what is it?

Ron Jeffries
www.XProgramming.com <http://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]

Nobody can decide on how much work they can reasonable accomplish. Such a commitment is impossible. This is a very harsh form of coercion - making the team produce their own commitment, and then holding them to it. Whenever I see this as a ScrumMaster I ask my team to commit to no more than half of what they absolutely believe they can do - and it's still wrong sometimes.  If, of course, you are not holding them to it, and they're not holding themselves to it, then it's not a commitment, it is merely a goal. Not quite as bad, but goals turn into commitments at the drop of a hat.

Your last sentence is correct. Their commitment is to do as much as they can while reaching done and working at a sustainable pace. This has nothing to do with committing to  stories at the sprint planning meeting.

By the way, I'm not even a big fan of forecasts. As long as management can see, and understand, how much has been done then they have enough info to extrapolate forward. Of course, understanding how much has been done is the issue - adn hence the big arguments about StoryPoints and other ways of measuring size. Sorry, couldn't help it...  :)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

On 3/30/2013 11:00 AM, John Clifford wrote:

[George Dinwiddie]

Dan,

My observation has been that the examplars don't translate across teams.
Only one team, at most, is likely to have done the examplar, so the
others are merely guessing. There is not generally, in my experience, a
lot of shared experience between teams. It strikes me that this could
possibly be remedied, but would be expensive in terms of time and effort
to do so.

- George

On 3/30/13 2:34 PM, Dan Rawsthorne wrote:
> Actually, George. I don't think the hope of correlated estimates goes
> out the window. When doing the estimations we often use an examplar - a
> story we are comparing all the stories to. Maybe we use multiple
> exemplars, a Small, Medium, and Large. Then, getting consistent
> estimates across teams is merely a matter of using correlated examplars,
> and then trusting the teams. Expanding your sense of community, so to speak.
> Dan Rawsthorne, PhD, PMP, CST

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

>> - George
>>
>>
>>>
>>> What kind of size is important to you? we know that since we've added
>>> functionality (a new test passes), that we've made the system larger
>>> larger. How much larger? One test's worth... maybe that's good enough.
>>> Ken now defines Velocity as #Features/$100K. Does this make sense? Sure,
>>> once everybody agrees on what it means.
>>>
>>> Now, this thread started with the question of standardizing the
>>> estimations. That's a different issue. Once we figure out what size is,
>>> then we can worry about normalizing it so that it can be added and
>>> compared. One step at a time.
>>>

>>> Dan ;-)

>>> Dan Rawsthorne, PhD, PMP, CST
>>> 3Back.com <http://www.3Back.com>
>>> Author of /Exploring Scrum: the Fundamentals/
>>> <http://www.amazon.com/dp/1461160286>
>>> On 3/29/2013 12:34 PM, Ron Jeffries wrote:
>>>> Dan,
>>>>
>>>> On Mar 29, 2013, at 3:25 PM, Dan Rawsthorne
>>>> <dan.raw...@drdansplace.com
>>>> <mailto:dan.raw...@drdansplace.com>> wrote:
>>>>
>>>>> Use Cases, Function Points, features, etc. How much stuff is being
>>>>> built. The units used are varied and often process dependent. In my
>>>>> world they are the things that StoryPoints are a relative measure of.
>>>>> They are hard to get at...
>>>>
>>>> Use cases are not constant sized, nor sized at all. Seems unlikely
>>>> that two projects each with 500 use cases are anything like the same
>>>> "size".
>>>>
>>>> Function points were intended to serve as size, but as I read the
>>>> literature, no two projects estimate FP similarly.
>>>>
>>>> Features, come on, get real. Completely random in size.
>>>>
>>>> Size in square meters and square feet are different numbers but the
>>>> same size.
>>>>
>>>> You keep saying that size is important. If it doesn't have units and

>>>> is not comparable … what is it?

>>>>
>>>> Ron Jeffries
>>>> www.XProgramming.com <http://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
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Scrum Alliance - transforming the world of work." group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scrumallianc...@googlegroups.com.
> To post to this group, send email to scruma...@googlegroups.com.
> Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[John Clifford]

Dan, you are reading a lot of things into my response that I'm not saying, so don't ask me to defend a position I'm not taking.

The sprint commitment isn't do-or-die, it's a goal that we the team realistically believe can be accomplished. It is the hypothesis that we test in the experiment called a sprint, and we either prove or disprove it (by doing more, or less). Whatever the result, we learn so we can improve.

One thing that dismays me is how many seem to resist any sort of measurement, as if measurement is inherently harmful...or even evil. PDCA is the heart of Scrum... inspect-and-act. If we don't inspect, then our actions are random and instead of improvement we perform the Drunkard's Walk.

Yes, measurement has been misused... so what? Don't let misuse be an excuse to avoid measurement as a part of improvement. Stand up against dysfunctional management instead of avoiding the problem.

[Bachan.anand]

On 2013-03-31, at 8:23 AM, John Clifford <john.c...@construx.com> wrote:

> Dan, you are reading a lot of things into my response that I'm not saying, so don't ask me to defend a position I'm not taking.
>
> The sprint commitment isn't do-or-die, it's a goal that we the team realistically believe can be accomplished. It is the hypothesis that we test in the experiment called a sprint, and we either prove or disprove it (by doing more, or less). Whatever the result, we learn so we can improve.

The word commitment is so overloaded and I believe it is NOT fair to ask anyone to commit . It is better to ask people what they can realistically do in a period of time and in that process they ( the team) will be making a commitment to do their best . In other words when teams agree on what they can do within a time period they are making a commitment to themselves , it is not anyone else business ask them whether they are making a commitment or not . I think if we take this approach , we will see true commitment from teams..

>
> One thing that dismays me is how many seem to resist any sort of measurement, as if measurement is inherently harmful...or even evil. PDCA is the heart of Scrum... inspect-and-act. If we don't inspect, then our actions are random and instead of improvement we perform the Drunkard's Walk.
>
> Yes, measurement has been misused... so what? Don't let misuse be an excuse to avoid measurement as a part of improvement. Stand up against dysfunctional management instead of avoiding the problem.
>

[John Miller]

Commitment does not equal a guarantee of results.

Thanks,

John Miller

http://theagileschool.blogspot.com/

“Set patterns, incapable of adaptability, of pliability, only offer a better cage. Truth is outside of all patterns.” 
― Bruce Lee, Tao of Jeet Kune Do

[Dan Rawsthorne]

Yes, so what you have to do is get exemplars that are the same size, not necessarily the same exemplars

Dan Rawsthorne, PhD, PMP, CST
3Back.com

Author of Exploring Scrum: the Fundamentals

On 3/30/2013 5:22 PM, George Dinwiddie wrote:

Dan,

My observation has been that the examplars don't translate across teams. Only one team, at most, is likely to have done the examplar, so the others are merely guessing. There is not generally, in my experience, a lot of shared experience between teams. It strikes me that this could possibly be remedied, but would be expensive in terms of time and effort to do so.

�- George

�- George

What kind of size is important to you? we know that since we've added
functionality (a new test passes), that we've made the system larger
larger. How much larger? One test's worth... maybe that's good enough.
Ken now defines Velocity as #Features/$100K. Does this make sense? Sure,
once everybody agrees on what it means.

Now, this thread started with the question of standardizing the
estimations. That's a different issue. Once we figure out what size is,
then we can worry about normalizing it so that it can be added and
compared. One step at a time.

Dan� ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com <http://www.3Back.com>
Author of /Exploring Scrum: the Fundamentals/
<http://www.amazon.com/dp/1461160286>
On 3/29/2013 12:34 PM, Ron Jeffries wrote:

Dan,

On Mar 29, 2013, at 3:25 PM, Dan Rawsthorne
<dan.raw...@drdansplace.com
<mailto:dan.raw...@drdansplace.com>> wrote:

Use Cases, Function Points, features, etc. How much stuff is being
built. The units used are varied and often process dependent. In my
world they are the things that StoryPoints are a relative measure of.
They are hard to get at...

Use cases are not constant sized, nor sized at all. Seems unlikely
that two projects each with 500 use cases are anything like the same
"size".

Function points were intended to serve as size, but as I read the
literature, no two projects estimate FP similarly.

Features, come on, get real. Completely random in size.

Size in square meters and square feet are different numbers but the
same size.

You keep saying that size is important. If it doesn't have units and

is not comparable � what is it?

Ron Jeffries
www.XProgramming.com <http://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]

Then call it a goal or forecast, and not commitment. words matter.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

It does if you are committing to results. Or at least it becomes a force to kill yourselves trying to reach the results.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

 REGISTER NOW for the Scrum Gathering Las Vegas 2013 

[Michael Vizdos]

Words can be word smithed to death. This thread is a perfect example.

They can be and are abused by people.

While people are doing that I ask that the team do their best,  deliver, deliver,  deliver and the conversations and word smithing stops.

Mike Vizdos
Implementingscrum.com

[Howard Sublett]

Mike. I feel abused by your use of words. ;-)

Howard Sublett 

Sent from my iPad

[George Dinwiddie]

Dan,

On 3/31/13 1:56 AM, Dan Rawsthorne wrote:
> Yes, so what you have to do is get exemplars that are the same size, not
> necessarily the same exemplars

Easier said than done. And even a single team tends to vary over time.
Yes, an engineer would think that impossible since the reference story
for sizing hasn't changed. But I observe it in ever team I encounter.

- George

> Dan Rawsthorne, PhD, PMP, CST
> 3Back.com <http://www.3Back.com>
> Author of /Exploring Scrum: the Fundamentals/
> <http://www.amazon.com/dp/1461160286>

> On 3/30/2013 5:22 PM, George Dinwiddie wrote:
>> Dan,
>>
>> My observation has been that the examplars don't translate across
>> teams. Only one team, at most, is likely to have done the examplar, so
>> the others are merely guessing. There is not generally, in my
>> experience, a lot of shared experience between teams. It strikes me
>> that this could possibly be remedied, but would be expensive in terms
>> of time and effort to do so.
>>

>>>> - George
>>>>
>>>>
>>>>>
>>>>> What kind of size is important to you? we know that since we've added
>>>>> functionality (a new test passes), that we've made the system larger
>>>>> larger. How much larger? One test's worth... maybe that's good enough.
>>>>> Ken now defines Velocity as #Features/$100K. Does this make sense?
>>>>> Sure,
>>>>> once everybody agrees on what it means.
>>>>>
>>>>> Now, this thread started with the question of standardizing the
>>>>> estimations. That's a different issue. Once we figure out what size
>>>>> is,
>>>>> then we can worry about normalizing it so that it can be added and
>>>>> compared. One step at a time.
>>>>>

>>>>> Dan ;-)

>>>>> Dan Rawsthorne, PhD, PMP, CST
>>>>> 3Back.com <http://www.3Back.com>
>>>>> Author of /Exploring Scrum: the Fundamentals/
>>>>> <http://www.amazon.com/dp/1461160286>
>>>>> On 3/29/2013 12:34 PM, Ron Jeffries wrote:
>>>>>> Dan,
>>>>>>
>>>>>> On Mar 29, 2013, at 3:25 PM, Dan Rawsthorne
>>>>>> <dan.raw...@drdansplace.com
>>>>>> <mailto:dan.raw...@drdansplace.com>> wrote:
>>>>>>
>>>>>>> Use Cases, Function Points, features, etc. How much stuff is being
>>>>>>> built. The units used are varied and often process dependent. In my
>>>>>>> world they are the things that StoryPoints are a relative measure
>>>>>>> of.
>>>>>>> They are hard to get at...
>>>>>>
>>>>>> Use cases are not constant sized, nor sized at all. Seems unlikely
>>>>>> that two projects each with 500 use cases are anything like the same
>>>>>> "size".
>>>>>>
>>>>>> Function points were intended to serve as size, but as I read the
>>>>>> literature, no two projects estimate FP similarly.
>>>>>>
>>>>>> Features, come on, get real. Completely random in size.
>>>>>>
>>>>>> Size in square meters and square feet are different numbers but the
>>>>>> same size.
>>>>>>
>>>>>> You keep saying that size is important. If it doesn't have units and

>>>>>> is not comparable … what is it?

>>>>>>
>>>>>> Ron Jeffries
>>>>>> www.XProgramming.com <http://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
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Scrum Alliance - transforming the world of work." group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to scrumallianc...@googlegroups.com.
>>> To post to this group, send email to scruma...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Scrum Alliance - transforming the world of work." group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scrumallianc...@googlegroups.com.
> To post to this group, send email to scruma...@googlegroups.com.
> Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Dan Rawsthorne]

the "a single team tends to vary over time" comment indicates you believe that Size is affected by the team. My argument is, and has been, that the size of a Story is a function of the Story - not the Team. The Team estimates it, but does not affect it (except by the quality of its estimation, of course).

Dan Rawsthorne, PhD, PMP, CST
3Back.com

Author of Exploring Scrum: the Fundamentals

On 3/31/2013 11:50 AM, George Dinwiddie wrote:

Dan,

On 3/31/13 1:56 AM, Dan Rawsthorne wrote:

Yes, so what you have to do is get exemplars that are the same size, not
necessarily the same exemplars

Easier said than done. And even a single team tends to vary over time. Yes, an engineer would think that impossible since the reference story for sizing hasn't changed. But I observe it in ever team I encounter.

�- George

Dan Rawsthorne, PhD, PMP, CST
3Back.com <http://www.3Back.com>
Author of /Exploring Scrum: the Fundamentals/
<http://www.amazon.com/dp/1461160286>
On 3/30/2013 5:22 PM, George Dinwiddie wrote:

Dan,

My observation has been that the examplars don't translate across
teams. Only one team, at most, is likely to have done the examplar, so
the others are merely guessing. There is not generally, in my
experience, a lot of shared experience between teams. It strikes me
that this could possibly be remedied, but would be expensive in terms
of time and effort to do so.

�- George

�- George

What kind of size is important to you? we know that since we've added
functionality (a new test passes), that we've made the system larger
larger. How much larger? One test's worth... maybe that's good enough.
Ken now defines Velocity as #Features/$100K. Does this make sense?
Sure,
once everybody agrees on what it means.

Now, this thread started with the question of standardizing the
estimations. That's a different issue. Once we figure out what size
is,
then we can worry about normalizing it so that it can be added and
compared. One step at a time.

Dan� ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com <http://www.3Back.com>
Author of /Exploring Scrum: the Fundamentals/
<http://www.amazon.com/dp/1461160286>
On 3/29/2013 12:34 PM, Ron Jeffries wrote:

Dan,

On Mar 29, 2013, at 3:25 PM, Dan Rawsthorne
<dan.raw...@drdansplace.com
<mailto:dan.raw...@drdansplace.com>> wrote:

Use Cases, Function Points, features, etc. How much stuff is being
built. The units used are varied and often process dependent. In my
world they are the things that StoryPoints are a relative measure
of.
They are hard to get at...

Use cases are not constant sized, nor sized at all. Seems unlikely
that two projects each with 500 use cases are anything like the same
"size".

Function points were intended to serve as size, but as I read the
literature, no two projects estimate FP similarly.

Features, come on, get real. Completely random in size.

Size in square meters and square feet are different numbers but the
same size.

You keep saying that size is important. If it doesn't have units and

is not comparable � what is it?

Ron Jeffries
www.XProgramming.com <http://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

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

[George Dinwiddie]

Dan,

On 3/31/13 3:52 PM, Dan Rawsthorne wrote:
> the "a single team tends to vary over time" comment indicates you
> believe that Size is affected by the team. My argument is, and has been,
> that the size of a Story is a function of the Story - not the Team. The
> Team estimates it, but does not affect it (except by the quality of its
> estimation, of course).

The size of something not yet in existence is affected by the team doing
the estimation.

Look at that pile of rocks I want you to put over there. What size is
it? Is it bigger or smaller than the other pile of rocks I want?

- George

> Dan Rawsthorne, PhD, PMP, CST
> 3Back.com <http://www.3Back.com>
> Author of /Exploring Scrum: the Fundamentals/
> <http://www.amazon.com/dp/1461160286>

> On 3/31/2013 11:50 AM, George Dinwiddie wrote:
>> Dan,
>>
>> On 3/31/13 1:56 AM, Dan Rawsthorne wrote:
>>> Yes, so what you have to do is get exemplars that are the same size, not
>>> necessarily the same exemplars
>>
>> Easier said than done. And even a single team tends to vary over time.
>> Yes, an engineer would think that impossible since the reference story
>> for sizing hasn't changed. But I observe it in ever team I encounter.
>>

>> - George
>>
>>> Dan Rawsthorne, PhD, PMP, CST
>>> 3Back.com <http://www.3Back.com>
>>> Author of /Exploring Scrum: the Fundamentals/
>>> <http://www.amazon.com/dp/1461160286>
>>> On 3/30/2013 5:22 PM, George Dinwiddie wrote:
>>>> Dan,
>>>>
>>>> My observation has been that the examplars don't translate across
>>>> teams. Only one team, at most, is likely to have done the examplar, so
>>>> the others are merely guessing. There is not generally, in my
>>>> experience, a lot of shared experience between teams. It strikes me
>>>> that this could possibly be remedied, but would be expensive in terms
>>>> of time and effort to do so.
>>>>

>>>>>> - George
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> What kind of size is important to you? we know that since we've
>>>>>>> added
>>>>>>> functionality (a new test passes), that we've made the system larger
>>>>>>> larger. How much larger? One test's worth... maybe that's good
>>>>>>> enough.
>>>>>>> Ken now defines Velocity as #Features/$100K. Does this make sense?
>>>>>>> Sure,
>>>>>>> once everybody agrees on what it means.
>>>>>>>
>>>>>>> Now, this thread started with the question of standardizing the
>>>>>>> estimations. That's a different issue. Once we figure out what size
>>>>>>> is,
>>>>>>> then we can worry about normalizing it so that it can be added and
>>>>>>> compared. One step at a time.
>>>>>>>

>>>>>>> Dan ;-)

>>>>>>>> is not comparable … what is it?

>>>>>>>>
>>>>>>>> Ron Jeffries
>>>>>>>> www.XProgramming.com <http://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.

[Ron Jeffries]

Dan,

On Mar 31, 2013, at 3:52 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

> the "a single team tends to vary over time" comment indicates you believe that Size is affected by the team. My argument is, and has been, that the size of a Story is a function of the Story - not the Team. The Team estimates it, but does not affect it (except by the quality of its estimation, of course).

I keep asking, and if you're answering I'm not getting it:

What is "size"? What are the units of size? How can the true size be
determined?

What the heck IS this thing you call size?

Ron Jeffries
Etc etc

[Wouter Lagerweij]

Hi,

I'd like to add what I think is another variation to this discussion, that I'd appreciate comments on.

In my current project, we hadn't done estimation at all for the first 6 months. We had a rule that a user story was small enough to be completely done in about 2-3 days. That worked well enough. Often they still wouldn't be done in that time, but usually it was close enough.

Recently the project went into another phase, for which we wanted a little more idea of how far we still had to go. We held a few sizing sessions, where all four teams were present, planned functionality was discussed, and then each team did a silent grouping of the features/epics identified into three groups: small (<5 stories), medium (5 to 10 stories), large (10 to 15 stories). Anything bigger or unclear was put into 'parked' to have a more detailed look at later. We then did a central 'merge' of each team's sizing, where too much of a difference got a story parked, and adjacent sizing got the larger one selected.

In a way, this works around some of the discussion here. Stories don't have a size in story points, but they do have a grounding in (cycle) time. That grounding is a maximum only, of course, but since they're supposed to be small, that doesn't really matter.

The t-shirt size estimates have a built-in uncertainty, but in this process they are agreed upon by all teams. We could even track how many stories each feature turns out to really have, though I have my doubts about the value of that.

What do you think of this construction? Bad thing would be that it's a (disguised) estimation in time. Good thing might be that it allows for a common idea of the amount of work to be done. I'd be interested in view on how this will bite me in the... :-)

Wouter

 - George

<dan.rawsthorne@drdansplace.com

an email to scrumalliance+unsubscribe@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at
http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google
Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send

an email to scrumalliance+unsubscribe@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google
Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send

an email to scrumalliance+unsubscribe@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--

[Dan Rawsthorne]

Right. that why we need known exemplars, or a way to measure examplars, or something.

Dan Rawsthorne, PhD, PMP, CST
3Back.com

Author of Exploring Scrum: the Fundamentals

On 3/31/2013 3:07 PM, George Dinwiddie wrote:

Dan,

On 3/31/13 3:52 PM, Dan Rawsthorne wrote:

the "a single team tends to vary over time" comment indicates you
believe that Size is affected by the team. My argument is, and has been,
that the size of a Story is a function of the Story - not the Team. The
Team estimates it, but does not affect it (except by the quality of its
estimation, of course).

The size of something not yet in existence is affected by the team doing the estimation.

Look at that pile of rocks I want you to put over there. What size is it? Is it bigger or smaller than the other pile of rocks I want?

�- George

Dan Rawsthorne, PhD, PMP, CST
3Back.com <http://www.3Back.com>
Author of /Exploring Scrum: the Fundamentals/
<http://www.amazon.com/dp/1461160286>
On 3/31/2013 11:50 AM, George Dinwiddie wrote:

Dan,

On 3/31/13 1:56 AM, Dan Rawsthorne wrote:

Yes, so what you have to do is get exemplars that are the same size, not
necessarily the same exemplars

Easier said than done. And even a single team tends to vary over time.
Yes, an engineer would think that impossible since the reference story
for sizing hasn't changed. But I observe it in ever team I encounter.

�- George

Dan Rawsthorne, PhD, PMP, CST
3Back.com <http://www.3Back.com>
Author of /Exploring Scrum: the Fundamentals/
<http://www.amazon.com/dp/1461160286>
On 3/30/2013 5:22 PM, George Dinwiddie wrote:

Dan,

My observation has been that the examplars don't translate across
teams. Only one team, at most, is likely to have done the examplar, so
the others are merely guessing. There is not generally, in my
experience, a lot of shared experience between teams. It strikes me
that this could possibly be remedied, but would be expensive in terms
of time and effort to do so.

�- George

�- George

What kind of size is important to you? we know that since we've
added
functionality (a new test passes), that we've made the system larger
larger. How much larger? One test's worth... maybe that's good
enough.
Ken now defines Velocity as #Features/$100K. Does this make sense?
Sure,
once everybody agrees on what it means.

Now, this thread started with the question of standardizing the
estimations. That's a different issue. Once we figure out what size
is,
then we can worry about normalizing it so that it can be added and
compared. One step at a time.

Dan� ;-)

is not comparable � what is it?

Ron Jeffries
www.XProgramming.com <http://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

[Ron Jeffries]

Hi Wouter …

On Mar 31, 2013, at 6:46 PM, Wouter Lagerweij <wou...@lagerweij.com> wrote:

In my current project, we hadn't done estimation at all for the first 6 months. We had a rule that a user story was small enough to be completely done in about 2-3 days. That worked well enough. Often they still wouldn't be done in that time, but usually it was close enough.

Yes … reminds me of something we have said when we were there … :)

Recently the project went into another phase, for which we wanted a little more idea of how far we still had to go. We held a few sizing sessions, where all four teams were present, planned functionality was discussed, and then each team did a silent grouping of the features/epics identified into three groups: small (<5 stories), medium (5 to 10 stories), large (10 to 15 stories). Anything bigger or unclear was put into 'parked' to have a more detailed look at later. We then did a central 'merge' of each team's sizing, where too much of a difference got a story parked, and adjacent sizing got the larger one selected.

In a way, this works around some of the discussion here. Stories don't have a size in story points, but they do have a grounding in (cycle) time. That grounding is a maximum only, of course, but since they're supposed to be small, that doesn't really matter.

The t-shirt size estimates have a built-in uncertainty, but in this process they are agreed upon by all teams. We could even track how many stories each feature turns out to really have, though I have my doubts about the value of that.

What do you think of this construction? Bad thing would be that it's a (disguised) estimation in time. Good thing might be that it allows for a common idea of the amount of work to be done. I'd be interested in view on how this will bite me in the... :-)

I would imagine it will produce as good a result as one can get. There are probably quite a few algorithms that would do this, and since the guesses were made by people with actual experience, they'll be pretty good.

My concerns -- as I'm sure you know -- are not so much with the likelihood of inaccuracy as with the use of the estimates, whether they are good or not so good.

The smaller concern is that management will use the figures as promises, leading to pressure to get done "on time", leading to lower quality, higher defect rates, dogs and cats living together, and so on. I think you know how to avoid those things pretty well, though there is always danger.

My larger concern is that this kind of approach focuses on "getting it all done". The issue is in the middle: "it all". The second greatest power of an Agile project is not in getting things done, but in choosing what to get done … and what not to do at all. I am concerned that once one has this list of "it all", the focus turns to grinding it all out.

The greatest power of an Agile project -- of course -- is using the full creativity of the whole team to solve the problem rather than to complete the backlog. The PO and team consider the problem, and jointly work out truly creative solutions to the problem. These solutions will look like the backlog epics but not like detailed backlog items.

It sounds as if you've left both these options open, in that you've not actually created the detailed backlog items … just guessed "how many" stories they might be. 

So as a way to estimate -- which sometimes one does want to do -- this seems to me to be a fairly safe one. My overall concern isn't the same as some people, who think estimation isn't possible. I know it's possible. I just think it is not safe, and while I wouldn't hesitate to do it if I had to, I don't think it's a good tool to put in the hands of average and below-average teams. 

Of course all the teams represented here are above average … :)

Ron Jeffries

www.XProgramming.com

Everything that needs to be said has already been said.

But since no one was listening, everything must be said again. -- Andre Gide

[Dan Rawsthorne]

Ok, back to basics. A story is a request for something that provides value. So there are three things involved here: the effort to build that something, the something itself, and the value it provides. The something has size, even if it's hard to measure or even grok. For example, we're usually talking about functionality, right? So, the story is asking for a given functional test to pass that doesn't already. If nothing else, the size of the something is defined by that functional test. This passes, and it didn't before... functionality increased. Now, people doing functional sizing do it in many different ways. We know there is a size, but we don't agree on the units, or the method for sizing, or whatever. What is cool is that an estimation game can be used to get a relative measure of the size, nomatter what we think it is. . The size is Small. it is Large, whatever. When we have an exemplar, the sizing becomes consistent, and the team gets better at it. This thing is Small, this one is Large.

Now, if we have sizing, the hope is that the Effort expended on that something is proportional to the size with some relatively constant ratio. It won't be, of course, if environmental variables like the Team's Ability, or Technical Debt, or Organizational Noise, are changing. Then the amount of Effort it wakes will change. This is a good thing, as it makes the Environmental Variables externally visible... just sayin'... I discussed this in Chapter 3.7 in my book, which some Ron Jeffries guy said was "the best scrum book I have seen"... and I know that these fights we keep having are making the next book even better. Thanks for that :)

Now, about those units. What units do we use to measure a pile of rocks? Count, volume measurements, mass, whatever. It doesn't really matter. What matters is that we learn to do consistent estimations that prove to be useful to us.

Now, for a thought experiment to show that StoryPoints being a relative measure of Effort is not useful... Assume we have a team that makes completely accurate and precise estimates of relative effort. In other words, they estimate Size(Story) = Cx(Actual Effort it takes), where C is some constant. Then Velocity = (Sum(Size(Done Story))) = (Cx(Sum(Actual Effort for Done Story))) = Cx(Effort Expended in the Sprint), which is essentially constant, assuming a constant team working at a Sustainable Pace. In other words, Velocity always settles down because Teams get better at estimating. Unfortunately, the resulting Velocity is not a useful thing to people trying to make predictions of release dates, or manage the project.

Why is it not useful? Here are a couple of examples.

1. If a Team gets better, Velocity stays the same - the Team's sizing estimates adapt to the fact stories are getting easier. More gets done, but we don't know how much more. I call this the Alan Atlas conundrum. He asked (on this forum I think) "How come if my team is getting better their Velocity isn't increasing?"

2. If Technical Debt starts eating up the Team, the Velocity stays the same - the Team's sizing estimates adapt to the fact stories are getting harder. Less gets done, but we don't know how much more. BTW. this is the situation that causes Ken to define Velocity = #Features/$100K on pages 93-98 of the Enterprise and Scrum book, when describing adding Technical Debt as the mother of all problems.

Enough for now.

Anyway, good to see the games begin again. Talk to you later...  Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com

Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

Couldn't agree more, Ron. Estimates are only useful if they all a PM to manage. A bad PM can use them for evil, but my experience is that a bad PM will be evil nomatter what. And, even if they are evil, we still owe them Visibility. There is a basic contract here. Management's side is to make good decisions, and our side is to make everything Visible in order to allow them to make good decisions. We need to live up to our side of the bargain even if they don't - I think that Scrum requires that of us.

Dan Rawsthorne, PhD, PMP, CST
3Back.com

Author of Exploring Scrum: the Fundamentals

On 3/31/2013 5:37 PM, Ron Jeffries wrote:

Hi Wouter �

On Mar 31, 2013, at 6:46 PM, Wouter Lagerweij <wou...@lagerweij.com> wrote:

In my current project, we hadn't done estimation at all for the first 6 months. We had a rule that a user story was small enough to be completely done in about 2-3 days. That worked well enough. Often they still wouldn't be done in that time, but usually it was close enough.

Yes � reminds me of something we have said when we were there � :)

Recently the project went into another phase, for which we wanted a little more idea of how far we still had to go. We held a few sizing sessions, where all four teams were present, planned functionality was discussed, and then each team did a silent grouping of the features/epics identified into three groups: small (<5 stories), medium (5 to 10 stories), large (10 to 15 stories). Anything bigger or unclear was put into 'parked' to have a more detailed look at later. We then did a central 'merge' of each team's sizing, where too much of a difference got a story parked, and adjacent sizing got the larger one selected.

In a way, this works around some of the discussion here. Stories don't have a size in story points, but they do have a grounding in (cycle) time. That grounding is a maximum only, of course, but since they're supposed to be small, that doesn't really matter.

The t-shirt size estimates have a built-in uncertainty, but in this process they are agreed upon by all teams. We could even track how many stories each feature turns out to really have, though I have my doubts about the value of that.

What do you think of this construction? Bad thing would be that it's a (disguised) estimation in time. Good thing might be that it allows for a common idea of the amount of work to be done. I'd be interested in view on how this will bite me in the... :-)

I would imagine it will produce as good a result as one can get. There are probably quite a few algorithms that would do this, and since the guesses were made by people with actual experience, they'll be pretty good.

My concerns -- as I'm sure you know -- are not so much with the likelihood of inaccuracy as with the use of the estimates, whether they are good or not so good.

The smaller concern is that management will use the figures as promises, leading to pressure to get done "on time", leading to lower quality, higher defect rates, dogs and cats living together, and so on. I think you know how to avoid those things pretty well, though there is always danger.

My larger concern is that this kind of approach focuses on "getting it all done". The issue is in the middle: "it all". The second greatest power of an Agile project is not in getting things done, but in choosing what to get done � and what not to do at all. I am concerned that once one has this list of "it all", the focus turns to grinding it all out.

The greatest power of an Agile project -- of course -- is using the full creativity of the whole team to solve the problem rather than to complete the backlog. The PO and team consider the problem, and jointly work out truly creative solutions to the problem. These solutions will look like the backlog epics but not like detailed backlog items.

It sounds as if you've left both these options open, in that you've not actually created the detailed backlog items � just guessed "how many" stories they might be.�

So as a way to estimate -- which sometimes one does want to do -- this seems to me to be a fairly safe one. My overall concern isn't the same as some people, who think estimation isn't possible. I know it's possible. I just think it is not safe, and while I wouldn't hesitate to do it if I had to, I don't think it's a good tool to put in the hands of average and below-average teams.�

Of course all the teams represented here are above average � :)

Ron Jeffries

www.XProgramming.com

Everything that needs to be said has already been said.

But since no one was listening, everything must be said again. -- Andre Gide

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

[Ron Jeffries]

On Mar 31, 2013, at 8:57 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

Ok, back to basics. A story is a request for something that provides value. So there are three things involved here: the effort to build that something, the something itself, and the value it provides. The something has size, even if it's hard to measure or even grok.

You appear to be assuming that there is a thing called size, which you'll then use to prove that there is a thing called size.

For example, we're usually talking about functionality, right? So, the story is asking for a given functional test to pass that doesn't already. If nothing else, the size of the something is defined by that functional test. This passes, and it didn't before... functionality increased. Now, people doing functional sizing do it in many different ways. We know there is a size, but we don't agree on the units, or the method for sizing, or whatever. What is cool is that an estimation game can be used to get a relative measure of the size, nomatter what we think it is. . The size is Small. it is Large, whatever. When we have an exemplar, the sizing becomes consistent, and the team gets better at it. This thing is Small, this one is Large. 

Size. What is size? That's the question. I think you're trying to disguise the fact that you're trying to estimate TIME, the time to get the thing done.

Clearly you don't mean the memory imprint or the amount of storage for the source code ...

Now, if we have sizing, the hope is that the Effort expended on that something is proportional to the size with some relatively constant ratio. It won't be, of course, if environmental variables like the Team's Ability, or Technical Debt, or Organizational Noise, are changing. Then the amount of Effort it wakes will change. This is a good thing, as it makes the Environmental Variables externally visible... just sayin'... I discussed this in Chapter 3.7 in my book, which some Ron Jeffries guy said was "the best scrum book I have seen"... and I know that these fights we keep having are making the next book even better. Thanks for that :)

Ah. Size is "Effort". So you mean by size "how hard people work"? No, you're talking about time to do it. Why not just say that? If that's not it, why not say what it is.

Now, about those units. What units do we use to measure a pile of rocks? Count, volume measurements, mass, whatever. It doesn't really matter. What matters is that we learn to do consistent estimations that prove to be useful to us.

I'm not much into rocks. However, I am into software … could we talk about that?

Now, for a thought experiment to show that StoryPoints being a relative measure of Effort is not useful…

Wait wait wait. You have just said that "Size is (proportional to) Effort". And now you are saying that it's not useful?

Assume we have a team that makes completely accurate and precise estimates of relative effort. In other words, they estimate Size(Story) = Cx(Actual Effort it takes), where C is some constant. Then Velocity = (Sum(Size(Done Story))) = (Cx(Sum(Actual Effort for Done Story))) = Cx(Effort Expended in the Sprint), which is essentially constant, assuming a constant team working at a Sustainable Pace. In other words, Velocity always settles down because Teams get better at estimating. Unfortunately, the resulting Velocity is not a useful thing to people trying to make predictions of release dates, or manage the project.

Why is it not useful? Here are a couple of examples.

1. If a Team gets better, Velocity stays the same - the Team's sizing estimates adapt to the fact stories are getting easier. More gets done, but we don't know how much more. I call this the Alan Atlas conundrum. He asked (on this forum I think) "How come if my team is getting better their Velocity isn't increasing?"

2. If Technical Debt starts eating up the Team, the Velocity stays the same - the Team's sizing estimates adapt to the fact stories are getting harder. Less gets done, but we don't know how much more. BTW. this is the situation that causes Ken to define Velocity = #Features/$100K on pages 93-98 of the Enterprise and Scrum book, when describing adding Technical Debt as the mother of all problems.

Enough for now.

Ron Jeffries

www.XProgramming.com

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

[Ron Jeffries]

Grr, sorry, that got away from me. Ignore previous wire ...

On Mar 31, 2013, at 8:57 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

Ok, back to basics.

Ron Jeffries

www.XProgramming.com

There's no word for accountability in Finnish. 

Accountability is something that is left when responsibility has been subtracted. 

--Pasi Sahlberg

[Ron Jeffries]

Dan,

On Mar 31, 2013, at 9:07 PM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Couldn't agree more, Ron. Estimates are only useful if they all a PM to manage. A bad PM can use them for evil, but my experience is that a bad PM will be evil nomatter what. And, even if they are evil, we still owe them Visibility. There is a basic contract here. Management's side is to make good decisions, and our side is to make everything Visible in order to allow them to make good decisions. We need to live up to our side of the bargain even if they don't - I think that Scrum requires that of us.

Visibility is: you asked us to do these things. We did them. Look.

Ron Jeffries

www.XProgramming.com

Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham

[Dan Rawsthorne]

Everything tangible has size, Ron. It's a fundamental property of "stuff", right? and functionality is tangible, we can determine when we have more or less of it. and the phrase "more or less" implies a notion of size.

No, size is estimated, time is derived. BTW, that's a quote from Mike, not me... We know there's an increase in functionality. That increase is called functional size (that's a defintiion, and not mine, BTW). So, the question becomes, "how can we measure it?"

More comments below.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

On 3/31/2013 6:11 PM, Ron Jeffries wrote:

On Mar 31, 2013, at 8:57 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

Ok, back to basics. A story is a request for something that provides value. So there are three things involved here: the effort to build that something, the something itself, and the value it provides. The something has size, even if it's hard to measure or even grok.

You appear to be assuming that there is a thing called size, which you'll then use to prove that there is a thing called size.

Actually, no, I'm assuming there's a something. and all somethings have size.

For example, we're usually talking about functionality, right? So, the story is asking for a given functional test to pass that doesn't already. If nothing else, the size of the something is defined by that functional test. This passes, and it didn't before... functionality increased. Now, people doing functional sizing do it in many different ways. We know there is a size, but we don't agree on the units, or the method for sizing, or whatever. What is cool is that an estimation game can be used to get a relative measure of the size, nomatter what we think it is. . The size is Small. it is Large, whatever. When we have an exemplar, the sizing becomes consistent, and the team gets better at it. This thing is Small, this one is Large.�

Size. What is size? That's the question. I think you're trying to disguise the fact that you're trying to estimate TIME, the time to get the thing done.

No, I'm definitely not trying to estimate time. I can measure time. So when I measure some time spent, I need to know what I got for that time spent. How much "stuff" did I get for my expenditure of time? That is the fundamental question for a PM.

Clearly you don't mean the memory imprint or the amount of storage for the source code ...

That's a type of size. Not easily derived or estimated for a Story, though. Probably not too useful for a PM to use, but, yes, if a kind of size.

Now, if we have sizing, the hope is that the Effort expended on that something is proportional to the size with some relatively constant ratio. It won't be, of course, if environmental variables like the Team's Ability, or Technical Debt, or Organizational Noise, are changing. Then the amount of Effort it wakes will change. This is a good thing, as it makes the Environmental Variables externally visible... just sayin'... I discussed this in Chapter 3.7 in my book, which some Ron Jeffries guy said was "the best scrum book I have seen"... and I know that these fights we keep having are making the next book even better. Thanks for that :)

Ah. Size is "Effort". So you mean by size "how hard people work"? No, you're talking about time to do it. Why not just say that? If that's not it, why not say what it is.

No, size is not effort.� Effort is spent to get stuff. Stuff has size. If we're lucky, the effort spent is proportional to size of what we got. that's what makes velocity useful.

Now, about those units. What units do we use to measure a pile of rocks? Count, volume measurements, mass, whatever. It doesn't really matter. What matters is that we learn to do consistent estimations that prove to be useful to us.

I'm not much into rocks. However, I am into software � could we talk about that?

Probably not. Because I'd ask "how do you measure the size of a piece of software? What is the stuff that provided value to users? and how do we measure how much of it we have? We know that our regression test suite tells us how much of our stuff is working,

Now, for a thought experiment to show that StoryPoints being a relative measure of Effort is not useful�

Wait wait wait. You have just said that "Size is (proportional to) Effort". And now you are saying that it's not useful?

I'm saying saying that size being effort is not useful, yes.

Assume we have a team that makes completely accurate and precise estimates of relative effort. In other words, they estimate Size(Story) = Cx(Actual Effort it takes), where C is some constant. Then Velocity = (Sum(Size(Done Story))) = (Cx(Sum(Actual Effort for Done Story))) = Cx(Effort Expended in the Sprint), which is essentially constant, assuming a constant team working at a Sustainable Pace. In other words, Velocity always settles down because Teams get better at estimating. Unfortunately, the resulting Velocity is not a useful thing to people trying to make predictions of release dates, or manage the project.

Why is it not useful? Here are a couple of examples.

1. If a Team gets better, Velocity stays the same - the Team's sizing estimates adapt to the fact stories are getting easier. More gets done, but we don't know how much more. I call this the Alan Atlas conundrum. He asked (on this forum I think) "How come if my team is getting better their Velocity isn't increasing?"

2. If Technical Debt starts eating up the Team, the Velocity stays the same - the Team's sizing estimates adapt to the fact stories are getting harder. Less gets done, but we don't know how much more. BTW. this is the situation that causes Ken to define Velocity = #Features/$100K on pages 93-98 of the Enterprise and Scrum book, when describing adding Technical Debt as the mother of all problems.

Enough for now.

Ron Jeffries

www.XProgramming.com

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

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

�
�

[Dan Rawsthorne]

I think visibility is what you call transparency. Visiblity means that my results are visible to you, you can see what I've done. I've made it visible to you.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Ron Jeffries]

Dan,

On Mar 31, 2013, at 10:18 PM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

I think visibility is what you call transparency. Visiblity means that my results are visible to you, you can see what I've done. I've made it visible to you.

Tame thing. You asked us to do this. We did this. See it.

Putting "size" on it isn't about visibility or transparency. It's really not about much of anything.

[Dan Rawsthorne]

I said visibility is part of our contract with management. It was not part of the sizing discussion. IT was in reference to your comments about bad management using size estimates for evil. I was actually agreeing with you about that stuff.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[George Dinwiddie]

Dan,

On 3/31/13 10:17 PM, Dan Rawsthorne wrote:
> Everything tangible has size, Ron. It's a fundamental property of
> "stuff", right? and functionality is tangible, we can determine when we
> have more or less of it. and the phrase "more or less" implies a notion
> of size.

What is /tangible/ about software that's not yet written?

- George

>
> No, size is estimated, time is derived. BTW, that's a quote from Mike,
> not me... We know there's an increase in functionality. That increase is
> called functional size (that's a defintiion, and not mine, BTW). So, the
> question becomes, "how can we measure it?"
>
> More comments below.
> Dan Rawsthorne, PhD, PMP, CST

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

> On 3/31/2013 6:11 PM, Ron Jeffries wrote:
>>
>> On Mar 31, 2013, at 8:57 PM, Dan Rawsthorne <draws...@gmail.com

>> <mailto:draws...@gmail.com>> wrote:
>>
>>> Ok, back to basics. A story is a request for something that provides
>>> value. So there are three things involved here: the effort to build
>>> that something, the something itself, and the value it provides. The
>>> something has size, even if it's hard to measure or even grok.
>>
>> You appear to be assuming that there is a thing called size, which
>> you'll then use to prove that there is a thing called size.
>
> Actually, no, I'm assuming there's a something. and all somethings have
> size.
>>
>>> For example, we're usually talking about functionality, right? So,
>>> the story is asking for a given functional test to pass that doesn't
>>> already. If nothing else, the size of the something is defined by
>>> that functional test. This passes, and it didn't before...
>>> functionality increased. Now, people doing functional sizing do it in
>>> many different ways. We know there is a size, but we don't agree on
>>> the units, or the method for sizing, or whatever. What is cool is
>>> that an estimation game can be used to get a relative measure of the
>>> size, nomatter what we think it is. . The size is Small. it is Large,
>>> whatever. When we have an exemplar, the sizing becomes consistent,
>>> and the team gets better at it. This thing is Small, this one is Large.
>>

> No, size is not effort. Effort is spent to get stuff. Stuff has size.

> If we're lucky, the effort spent is proportional to size of what we got.
> that's what makes velocity useful.
>>>
>>> Now, about those units. What units do we use to measure a pile of
>>> rocks? Count, volume measurements, mass, whatever. It doesn't really
>>> matter. What matters is that we learn to do consistent estimations
>>> that prove to be useful to us.
>>

>> I'm not much into rocks. However, I am into software … could we talk

>> about that?
>
> Probably not. Because I'd ask "how do you measure the size of a piece of
> software? What is the stuff that provided value to users? and how do we
> measure how much of it we have? We know that our regression test suite
> tells us how much of our stuff is working,
>>>
>>> Now, for a thought experiment to show that StoryPoints being a

>>> relative measure of Effort is not useful…

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

>> If it is more than you need, it is waste. -- Andy Seidl
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Scrum Alliance - transforming the world of work." group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to scrumallianc...@googlegroups.com.
>> To post to this group, send email to scruma...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Scrum Alliance - transforming the world of work." group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scrumallianc...@googlegroups.com.
> To post to this group, send email to scruma...@googlegroups.com.
> Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Dan Rawsthorne]

once the story is done, the software is written. The Functional Size can be estimated beforehand - that's why it's an estimate and not a measurement. It can be measured afterwords to help you improve your estimations, too. Of course, the measurement technique varies based on on what school of functional size you belong to. I like COSMIC Function Points, personally.

Dan Rawsthorne, PhD, PMP, CST
3Back.com

Author of Exploring Scrum: the Fundamentals

On 3/31/2013 7:46 PM, George Dinwiddie wrote:

Dan,

On 3/31/13 10:17 PM, Dan Rawsthorne wrote:

Everything tangible has size, Ron. It's a fundamental property of
"stuff", right? and functionality is tangible, we can determine when we
have more or less of it. and the phrase "more or less" implies a notion
of size.

What is /tangible/ about software that's not yet written?

�- George

No, size is not effort.� Effort is spent to get stuff. Stuff has size.

If we're lucky, the effort spent is proportional to size of what we got.
that's what makes velocity useful.

Now, about those units. What units do we use to measure a pile of
rocks? Count, volume measurements, mass, whatever. It doesn't really
matter. What matters is that we learn to do consistent estimations
that prove to be useful to us.

I'm not much into rocks. However, I am into software � could we talk
about that?

Probably not. Because I'd ask "how do you measure the size of a piece of
software? What is the stuff that provided value to users? and how do we
measure how much of it we have? We know that our regression test suite
tells us how much of our stuff is working,

Now, for a thought experiment to show that StoryPoints being a

relative measure of Effort is not useful�

[Ron Jeffries]

Dan,

On Mar 31, 2013, at 11:04 PM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Functional Size

"There you go again." -- Ronald Reagan

Capitalizing the words does not cause the thing in question suddenly to exist. What is this thing you call size, functional size, and any/all other terms you've given it? You keep telling us what it's for, but not what it is or how to get it.

Is the functional size of an item the cycle time for producing the item? The cycle time less certain delay times? 

Ron Jeffries

www.XProgramming.com

Sometimes I give myself admirable advice, but I am incapable of taking it.

-- Mary Wortley Montagu

[Ron Jeffries]

Dan,

On Mar 29, 2013, at 11:46 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

The size of the Project is independent of Teams. The cost of the Project is Team dependent. The three assumptions I gave are independent, and they need to be in order to manage the project effectively. All standard Project Management, btw, even though most people calling themselves project managers don't have a clue. Pity... we can hope all they need is education. I guess if we can believe we can turn Teams into scrum teams, we should be able to believe we can turn project managers into proper project managers. 

The aforementioned assumptions were:

Examples of Assumptions (original baselines):
 - this Project is worth XX  StoryPoints (this requires SPs that are about size, not effort)
 - a StoryPoint will take HH Hours on average
 - an Hour will cost DD Dollars on average

Note that "size" is still undefined. So is "effort". We can guess from your statement that size and effort are not strongly correlated, or either would do.

We can guess from these assumptions what the PM (ptooie) is thinking. He's planning to conclude that the time for the project is about HH*XX hours and about DD*XX dollars.

I think we can probably agree closely enough that given hours we can compute cost using dollars per hour. Even if not, it's separate from the calculation of hours for the project.

We wish to be able to say Project Hours PH approximately equals the number of "story points" in the project times the average number of hours for a story point. 

I think we can probably agree as well that for this to work, the variance around the story point to hours mapping has to be small. This is probably what we mean by "standardizing" or "normalizing" story points. 

Now then. Each team has its own way of computing story points. They are not necessarily linear. They are not even necessarily numeric. S, M, L, XL is a not uncommon way of doing it. I have not seen a team using AA, A, B, C D, DD, but they may be out there. It doesn't matter. 

We can observe the cycle time for each team. We have reason to do so as well. We can therefore come up with a table of their average performance, say:

S: 1 day

M: 2 days

L: 5 days

XL: 13 days

As PM (blargh) we want to be able to add all these things up, subject to a number of caveats about what adding them up can and cannot tell us. We'll touch on those below, time permitting.

With the wave of a hand, this very hand, we decide that PMSP (Project Manager (gack) Story Points) have the convenient property that HH (hours per PMSP) is 1. It follows that for the team above,

S is 1 PMSP

M is 2 PMSP

L is 5 PMSP

XL is 13 PMSP

We look at their backlog, all nicely estimated in t-shirt sizes and trivially convert it to PMSP. If their backlog contains epics, which it bloody well should, we can ask them to estimate it in their standard way, as Wouter described, only with multiple sizes instead of the ideal all-sliced-down-to-standard-size approach that he used.

To the extent that standardizing/normalizing story points works, this also works, and avoids all the hassle of having the teams change what they are doing. Nicely isolates this to the office of the PM (hawwwk).

Note that PMSP meets the requirement of being independent of team, TO THE EXTENT THAT ANY NUMBER CAN. Previous emphasis exists because story points are ENTIRELY team dependent. They are not even well-ordered across teams. That is, if team A thinks that S1 < S2 < S3, team B may think that S2 < S3 < S1. And they may both be right.

We cannot hand stories between teams and preserve the ordering. We cannot remove people from teams and preserve the ordering. We quite likely cannot even add people to a team and preserve ordering. 

All that notwithstanding, there is no need to ask teams to estimate in any way other than the one they want to use, because it is literally trivial for anyone who wants to see the big picture to convert to whatever standard form they want. For extra credit, someone should build a very expensive Agile PM (rork) app to do this.

HOWEVER, this is still the wrong thing to do when we look at the risks of doing it. 

First, it focuses attention on completion of "everything", and is likely to focus attention on why team B can't do as many t-shirts as team A. It's possible that some company somewhere would not ask this question, but I've never encountered it.

Second, and more important, the whole bloody point of Agile, and Scrum as an instance of Agile, is to steer the project to success by treating the development process as a machine for producing Features/Time, and choosing what to do based on the time available. Basically one creates a ready-to-ship product that always has the best possible capability for today's date, and ships it when "best possible" is "functional enough".

Third, and most important, focus on completion from a list broken down into elements that we can add up eliminate all the creativity that comes from frequent interaction between business and development, solving problems rather than just cranking out predetermined solutions.

So: if you're going to do it, do it at the PM (blech) level and keep it away from the teams, because it would be wasteful to do otherwise. And better yet, don't do it, because whether you think you want it or not, it's not the best thing to do.

Ron Jeffries

www.XProgramming.com

Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

[Dan Rawsthorne]

Functional Size is an already defined term, I'm just using it. I know you will find the definition inadequate, but here it is: "Functional Size is a size of the software derived by quantifying the Functional User Requirements, which are a subset of the User Requirements." It is self-evident to me that it exists, the fun part is how you do the  quantification. The easiest way is to simply count them, and there are also very complicated ways to do it, like IFPUG Function Points. The units used are usually called <something> Points, like Function Points or Feature Points or Use Case Points or (dare I say it) Story Points. Simply counting Requirements (Stories) in order to provide Velocity is the simplest way, and represents a size of "1" for each Story. Are you still doing it this way, Ron?

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

Well, we hope that Size and Effort are correlated, because this is the basis for almost all planning. There is not a StoryPoint to Effort mapping, it is derived. We have actual effort to work with, it is no derived from StoryPoints. That's like saying the number of fence posts in a fence is a function of how much you paid for it. Finding the 'right' size mapping that correlates with effort (and is not, itself, effort) is the whole idea behind the size we're discussing here. For example, our experience with object-orientation has convinced us that SLOC is NOT a good size measure for program management purposes - a better one seems to be total methods and properties.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

On 4/1/2013 6:44 AM, Ron Jeffries wrote:

Dan,

On Mar 29, 2013, at 11:46 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

The size of the Project is independent of Teams. The cost of the Project is Team dependent. The three assumptions I gave are independent, and they need to be in order to manage the project effectively. All standard Project Management, btw, even though most people calling themselves project managers don't have a clue. Pity... we can hope all they need is education. I guess if we can believe we can turn Teams into scrum teams, we should be able to believe we can turn project managers into proper project managers. 

The aforementioned assumptions were:

Examples of Assumptions (original baselines):
 - this Project is worth XX  StoryPoints (this requires SPs that are about size, not effort)
 - a StoryPoint will take HH Hours on average
 - an Hour will cost DD Dollars on average

Note that "size" is still undefined. So is "effort". We can guess from your statement that size and effort are not strongly correlated, or either would do.

StoryPoint = result of estimation game, a quantification of size as the team sees it, ignoring effort (now it's well defined)
Effort = Time spent on something by the Team (now it's well defined)

We can guess from these assumptions what the PM (ptooie) is thinking. He's planning to conclude that the time for the project is about HH*XX hours and about DD*XX dollars.

No, these are baseline assumptions, not conclusions. (good) PMs don't make conclusions, they look at data and try to keep up.

I think we can probably agree closely enough that given hours we can compute cost using dollars per hour. Even if not, it's separate from the calculation of hours for the project.

Agreed. that's why they are separate, independent, assumptions

We wish to be able to say Project Hours PH approximately equals the number of "story points" in the project times the average number of hours for a story point.

Well, at any given time,. this defines the running average of hours per storypoint. if we're lucky, this levels out and the project becomes manageable. we might not get lucky.

I think we can probably agree as well that for this to work, the variance around the story point to hours mapping has to be small. This is probably what we mean by "standardizing" or "normalizing" story points.

No. Normalizing StoryPoints is making sure that each  StoryPoint represents the "same amount" of functionality. the hours per StoryPoint is a derived number. If it does smooth out, then that is very cool, and the project is boring - which is what you want.

Now then. Each team has its own way of computing story points. They are not necessarily linear. They are not even necessarily numeric. S, M, L, XL is a not uncommon way of doing it. I have not seen a team using AA, A, B, C D, DD, but they may be out there. It doesn't matter.

And when we talk about improving estimations, we are talking about making them linear and more consistent. Size may not be numeric, but points are...

We can observe the cycle time for each team. We have reason to do so as well. We can therefore come up with a table of their average performance, say:

S: 1 day

M: 2 days

L: 5 days

XL: 13 days

As PM (blargh) we want to be able to add all these things up, subject to a number of caveats about what adding them up can and cannot tell us. We'll touch on those below, time permitting.

These are running averages. The PM is observing the team, monitoring flow. Making his/her best guess about things...

With the wave of a hand, this very hand, we decide that PMSP (Project Manager (gack) Story Points) have the convenient property that HH (hours per PMSP) is 1. It follows that for the team above,

S is 1 PMSP

M is 2 PMSP

L is 5 PMSP

XL is 13 PMSP

We look at their backlog, all nicely estimated in t-shirt sizes and trivially convert it to PMSP. If their backlog contains epics, which it bloody well should, we can ask them to estimate it in their standard way, as Wouter described, only with multiple sizes instead of the ideal all-sliced-down-to-standard-size approach that he used.

Decidedly non-trivial. And we haven't touched on Epic sizing yet. But there are ways to estimate them, yes. And we need experts to do the estimations, so it probably involves the development team who are closest to the logical design and all that...

To the extent that standardizing/normalizing story points works, this also works, and avoids all the hassle of having the teams change what they are doing. Nicely isolates this to the office of the PM (hawwwk).

Note that PMSP meets the requirement of being independent of team, TO THE EXTENT THAT ANY NUMBER CAN. Previous emphasis exists because story points are ENTIRELY team dependent. They are not even well-ordered across teams. That is, if team A thinks that S1 < S2 < S3, team B may think that S2 < S3 < S1. And they may both be right.

We cannot hand stories between teams and preserve the ordering. We cannot remove people from teams and preserve the ordering. We quite likely cannot even add people to a team and preserve ordering.

All that notwithstanding, there is no need to ask teams to estimate in any way other than the one they want to use, because it is literally trivial for anyone who wants to see the big picture to convert to whatever standard form they want. For extra credit, someone should build a very expensive Agile PM (rork) app to do this.

Yes, when the team is estimating their effort when they are managing themselves, this is their problem, not the PM's.

HOWEVER, this is still the wrong thing to do when we look at the risks of doing it. 

First, it focuses attention on completion of "everything", and is likely to focus attention on why team B can't do as many t-shirts as team A. It's possible that some company somewhere would not ask this question, but I've never encountered it.

No to the first statement. It explicitly gives the PM the tools to decide how much is likely to be developed, and allows informed re-scoping, re-budgeting, or whatever is needed to bring the project in balance.

Second, and more important, the whole bloody point of Agile, and Scrum as an instance of Agile, is to steer the project to success by treating the development process as a machine for producing Features/Time, and choosing what to do based on the time available. Basically one creates a ready-to-ship product that always has the best possible capability for today's date, and ships it when "best possible" is "functional enough".

Yes, exactly. That doesn't change - no reason for it to. your first sentence is precisely the reason to use it. It is what gives you the information needed to determine what can be done based on the time available. (more specifically, how much can be done in the time available). Or, to put it backwards, it gives management the tools to use to be able to guess what is going on. Many organization do this in an ad hoc way, and some use metrics.

Third, and most important, focus on completion from a list broken down into elements that we can add up eliminate all the creativity that comes from frequent interaction between business and development, solving problems rather than just cranking out predetermined solutions.

I knw what you're trying to say, and I agree. You mean "detailed" elements, and I agree - that's reinventing the complete requirements document that we know doesn't work. Have a budget, have a shopping list, of whatever granularity you want. Then go...

So: if you're going to do it, do it at the PM (blech) level and keep it away from the teams, because it would be wasteful to do otherwise. And better yet, don't do it, because whether you think you want it or not, it's not the best thing to do.

Yes, this is somthing that stays away from the teams. This statement is the major point of the next book - keep the PM out of the Team room!

So, I'm going to try to stay away from this thread for a while. I've had the good discussion I need to improve the Sizing portion of the new book. So, I'm going to focus on that for a while. This is a useful, and fun, diversion - bit it is a diversion.  Dan  ;-)

Ron Jeffries

www.XProgramming.com

Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

[Michael Vizdos]

What is this role of PM that Dan writes about,  Ron (blechs) about and what the team really should be doing... Delivering.

All of this estimation talk seems like fantasy land and long term planning for some outside stakeholder to make the power points look good.

Here's the thing. In that world of power points and Gantt charts people preparing them will lie anyway. I mean present what the boss wants to hear.

So.

My recommendation with teams is do some rough estimations and then Deliver deliver deliver.

The conversation changes when your customers and end users can do Something besides approving Gantt charts and slick PowerPoint presentations.

Deliver. Deliver. Deliver.

Mike Vizdos
Implementingscrum.com

[Ron Jeffries]

Dan,

On Apr 1, 2013, at 12:01 PM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Well, we hope that Size and Effort are correlated, because this is the basis for almost all planning.

Yes. The point remains that //between teams//, the topic of this thread, they are not necessarily correlated (though they probably are somewhat decently correlated).

There is not a StoryPoint to Effort mapping, it is derived. We have actual effort to work with, it is no derived from StoryPoints.

Yes. As I said, we get the mapping by looking at what happens.

That's like saying the number of fence posts in a fence is a function of how much you paid for it. Finding the 'right' size mapping that correlates with effort (and is not, itself, effort) is the whole idea behind the size we're discussing here. For example, our experience with object-orientation has convinced us that SLOC is NOT a good size measure for program management purposes - a better one seems to be total methods and properties. 

Yes. As we see in the ISO docs on "Functional Size", no one agrees on how to do it. I believe this is primarily because there is no way to do it that actually works, but that's just my theory.

It remains true that we can measure to get SP->HH and HH->DD is "easy". It's just that after that things go badly.

I suppose if we do anything more rational than roll D&D dice to get story "size", we're likely to have some reasonable correlation. My points here remain:

1. If you're going to recommend sizing, and even more if you're going to recommend standard sizing, I think you need to say what it is and how to do it.

2. I think it is quite risky to recommend the above at large, since by your own theory it requires a "competent PM" to use it well.

Ron Jeffries

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.

[Dan Rawsthorne]

Well, the book will do two things, among others. It will define a competent PM, and it will be quite clear on sizing recommendations. In fact, the second part is on its second iteration right now. It's about 70 pages long, and talks about stories, epics, and everything else I can think of.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Guarino]

Wow, guess that teaches me to go on Easter Vacation.

I have read through all these responses, and quite honestly, several of these things all go through my mind as well, however I could never get to these levels.

I don't think its good enough of a development shop to say "We are working hard, see everything we have done?".  I developed for 20 years before I moved to Dev Manager and now to ScrumMaster.  I believe I see both sides of this story, though I didn't think of everything in this thread, thanks to my friends for bringing up all the sides.

I believe we owe more than that to our management team, and even our product owner and project manager and anyone else that is looking for information.  Having a team with no sense of commitment sounds broken to me, agile, waterfall or any other cool word we can come up with.

So finding this balance, is the purpose of my admittedly awkward original post.  I can't tell you what I want to compare, and I can't tell you what I want, because I don't know yet.  Maybe it is a solution looking for a problem.  What I do know, is that having multiple teams doing different development styles on different projects is impossible to go through in a meeting of people who care.

Standardizing on TShirt sizes, with no set rules gets us somewhere.  I am not sure where, but we could certainly derive cycle times from each size.  I already started running these numbers across teams, and I find results that make no sense.  I show a, way to similar, cycle time for a 1 point story and a 3 point story.  So we can start to see that no matter the story size, it takes the same amount of time.  So I can start to look at QA cycles or merging issues perhaps.  

After typing some, I feel I am trying to find my way down a stream.  I don't know whats at the end (hopefully not waterfall (pun intended)).  But if transparency is good, then multiple teams showing congruent transparency seems good too, right?

I am not dismissing anything in this thread, and I plan to reread it through again, because so many great points were made in here.  Also, not sure who said it, but the whole purpose of this is to NOT LIE in the status meeting.

I appreciate all the input, and would love more actually, as long as we keep it civil, well civil enough for the internet at least.

[Wouter Lagerweij]

Hi Ron, 

On Mon, Apr 1, 2013 at 2:37 AM, Ron Jeffries <ronje...@acm.org> wrote:

Hi Wouter …

On Mar 31, 2013, at 6:46 PM, Wouter Lagerweij <wou...@lagerweij.com> wrote:

In my current project, we hadn't done estimation at all for the first 6 months. We had a rule that a user story was small enough to be completely done in about 2-3 days. That worked well enough. Often they still wouldn't be done in that time, but usually it was close enough.

Yes … reminds me of something we have said when we were there … :)

Yes! We do listen, you know. Sometimes. :-)

 

Recently the project went into another phase, for which we wanted a little more idea of how far we still had to go. We held a few sizing sessions, where all four teams were present, planned functionality was discussed, and then each team did a silent grouping of the features/epics identified into three groups: small (<5 stories), medium (5 to 10 stories), large (10 to 15 stories). Anything bigger or unclear was put into 'parked' to have a more detailed look at later. We then did a central 'merge' of each team's sizing, where too much of a difference got a story parked, and adjacent sizing got the larger one selected.

In a way, this works around some of the discussion here. Stories don't have a size in story points, but they do have a grounding in (cycle) time. That grounding is a maximum only, of course, but since they're supposed to be small, that doesn't really matter.

The t-shirt size estimates have a built-in uncertainty, but in this process they are agreed upon by all teams. We could even track how many stories each feature turns out to really have, though I have my doubts about the value of that.

What do you think of this construction? Bad thing would be that it's a (disguised) estimation in time. Good thing might be that it allows for a common idea of the amount of work to be done. I'd be interested in view on how this will bite me in the... :-)

I would imagine it will produce as good a result as one can get. There are probably quite a few algorithms that would do this, and since the guesses were made by people with actual experience, they'll be pretty good.

My concerns -- as I'm sure you know -- are not so much with the likelihood of inaccuracy as with the use of the estimates, whether they are good or not so good.

The smaller concern is that management will use the figures as promises, leading to pressure to get done "on time", leading to lower quality, higher defect rates, dogs and cats living together, and so on. I think you know how to avoid those things pretty well, though there is always danger.

This is certainly a danger/reality. We do have one of those seemingly mythical good PMs. But then there's the program manager, and the layers of management he's answering to. No matter how explicit we make the uncertainty in our estimates, I'm sure someone in that chain is overpromising...

My larger concern is that this kind of approach focuses on "getting it all done". The issue is in the middle: "it all". The second greatest power of an Agile project is not in getting things done, but in choosing what to get done … and what not to do at all. I am concerned that once one has this list of "it all", the focus turns to grinding it all out.

This is also happening. We're doing the exercise of estimation to show that 'it all' is already too much, and putting up a huge story map (though we call it a 'product breakdown' to keep the PM side comfortable) that should encourage flexibility in scope. But... 

 

The greatest power of an Agile project -- of course -- is using the full creativity of the whole team to solve the problem rather than to complete the backlog. The PO and team consider the problem, and jointly work out truly creative solutions to the problem. These solutions will look like the backlog epics but not like detailed backlog items.

It sounds as if you've left both these options open, in that you've not actually created the detailed backlog items … just guessed "how many" stories they might be. 

It is a continuous battle to keep that flexibility in there. I'm not sure whether the estimations will end up helping or hurting that. We did exactly what you describe: just guess the amount of stories, or flag as too big/uncertain. That worked fairly well, but of course there was a lot that was parked as 'uncertain', and further discussion of those have tended to go into too much detail. And the tendency to do horizontal slicing there get's in the way of exactly that 'greatest power' thing... We will correct that, as far as possible, but it's definitely not ingrained in the teams yet.

 

So as a way to estimate -- which sometimes one does want to do -- this seems to me to be a fairly safe one. My overall concern isn't the same as some people, who think estimation isn't possible. I know it's possible. I just think it is not safe, and while I wouldn't hesitate to do it if I had to, I don't think it's a good tool to put in the hands of average and below-average teams. 

Of course all the teams represented here are above average … :)

Ah, you didn't get the memo? All teams are not legally required to be above average.

All the risks you mention are at issue in this situation, but sometimes it just can't be avoided. We'll just have to keep managing the managing:-)

But at least the risk of sharing estimates between multiple teams is a very minor one for us...

thanks!

Wouter

 

[Guarino]

I know, I shouldnt reply to my own post, but I forgot something :)

Someone typed that we want to learn and adapt.  Perhaps this is an avenue for that on a devops type level.  Each team retro's, all that is fine, sometimes they even find ways to make things better/more efficient.  But what about things that teams don't see, that could be seen on a greater level.

Team A cycle time is 50% faster than Team B every sprint for all 5pt stories.

If we were standardized, I think this could become a topic for a retro.  Lets go see what Team A is doing, are they using some automated tool, or perhaps they are skipping code reviews.  Who knows, how can we know until we can find ways to see teams at the same level.

I wanted to argue the point made, again not sure who, that we DO want to measure the effects of people moving teams.  In an agile shop of multiple teams on multiple projects, the priorities change quite a bit.  I know its not optimal, but one valid thing all companies strive for is to ensure the correct number of resources are on projects. 

Sorry, I know its just more abstract stuff, but wanted to add it.

[Wouter Lagerweij]

On Mon, Apr 1, 2013 at 9:39 PM, Guarino <sofa.k...@gmail.com> wrote:

Wow, guess that teaches me to go on Easter Vacation.

I have read through all these responses, and quite honestly, several of these things all go through my mind as well, however I could never get to these levels.

I don't think its good enough of a development shop to say "We are working hard, see everything we have done?".  I developed for 20 years before I moved to Dev Manager and now to ScrumMaster.  I believe I see both sides of this story, though I didn't think of everything in this thread, thanks to my friends for bringing up all the sides.

I believe we owe more than that to our management team, and even our product owner and project manager and anyone else that is looking for information.  Having a team with no sense of commitment sounds broken to me, agile, waterfall or any other cool word we can come up with.

Don't misunderstand that discussion: Not committing to a certain amount of work done at the end of a sprint does not mean the team is not committed to their work/project. Mostly a semantics discussion:-)

 

So finding this balance, is the purpose of my admittedly awkward original post.  I can't tell you what I want to compare, and I can't tell you what I want, because I don't know yet.  Maybe it is a solution looking for a problem.  What I do know, is that having multiple teams doing different development styles on different projects is impossible to go through in a meeting of people who care.

Standardizing on TShirt sizes, with no set rules gets us somewhere.  I am not sure where, but we could certainly derive cycle times from each size.  I already started running these numbers across teams, and I find results that make no sense.  I show a, way to similar, cycle time for a 1 point story and a 3 point story.  So we can start to see that no matter the story size, it takes the same amount of time.  So I can start to look at QA cycles or merging issues perhaps.  

So maybe there are no separate categories for 1 and 3 point stories, but simply a category 1-5 (Small), which has a related average cycle time and deviations. You might just have found a little proof for yourself that estimations are inherently uncertain:-) 

And maybe there are parts of your development process that take a constant amount of time. Deployment perhaps? Or the time needed to run your (automated?) tests? 

Don't merge issues, that will hide process problems. Do a little analysis (value stream map?), and find out where you could improve process by changing rules or automation.

 

After typing some, I feel I am trying to find my way down a stream.  I don't know whats at the end (hopefully not waterfall (pun intended)).  But if transparency is good, then multiple teams showing congruent transparency seems good too, right?

I am not dismissing anything in this thread, and I plan to reread it through again, because so many great points were made in here.  Also, not sure who said it, but the whole purpose of this is to NOT LIE in the status meeting.

I appreciate all the input, and would love more actually, as long as we keep it civil, well civil enough for the internet at least.

Hey, you have interesting work ahead of you. Enjoy:-)

Wouter

[Michael James]

On Apr 1, 2013, at 12:39 PM, Guarino <sofa.k...@gmail.com> wrote:

Also, not sure who said it, but the whole purpose of this is to NOT LIE in the status meeting.

One way to avoid lying in status meetings would be to stop having status meetings.  The meeting that matters to people outside the team is the Sprint Review Meeting, where we see a potentially shippable product increment, or not.

--mj

(Michael)

[Dan Rawsthorne]

Yes, there are no status meetings in scrum. If you have them for some other non-scrum reason, then don't lie.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Yves Hanoulle]

Well in a sense a standup is also a status meeting.

With the difference that the status is for the team.

Some people don't get that when they start with scrum...

Scrambled by my Yphone

[Michael James]

On Apr 1, 2013, at 10:02 AM, Ron Jeffries <ronje...@acm.org> wrote:

As we see in the ISO docs on "Functional Size", no one agrees on how to do it. I believe this is primarily because there is no way to do it that actually works, but that's just my theory.

Last time I looked into this, the methods assumed most of the effort related to the complexity of the code.  But nowadays code complexity is only sometimes correlated to the time or effort of solving a problem. I asked one of the few remaining advocates of function points how he got around this, and his answer was to do so much up front analysis and design that a PBI would have to be mostly done before any function point estimate could be produced.

--mj

(Michael)

[Dan Rawsthorne]

Sorry, won't be much of a show today. Gotta run... but I should have about 70 pages on sizing ready for review next week sometime. So, anybody that wants to slog through that, send me a private email.� Dan� ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

On 3/29/2013 11:50 AM, Michael Vizdos wrote:

[getting a bag of popcorn for this the Dan and Ron show on this topic...]

Overall though... um... DO NOT compare points between teams.

Maybe do the "5 Whys" to see what people really need out of what they are asking.

Nothing good will come out of standardizing a story point.

Pick a date.� Pick a budget to fund the team(s) to that date.� Prioritize the scope (sorry... it's ALL not a priority one -- if it is perceived as the "real world" case then there is a different conversation altogether).

Thank you.

- mike vizdos
� �www.michaelvizdos.com/contact

On Fri, Mar 29, 2013 at 10:43 AM, Ron Jeffries <ronje...@acm.org> wrote:

Dan �

On Mar 29, 2013, at 11:46 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

The size of the Project is independent of Teams. The cost of the Project is Team dependent.�

What are the units of "size"?�

Ron Jeffries

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

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

�
�

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

�
�

[George Dinwiddie]

Yves,

On 4/2/13 1:59 AM, Yves Hanoulle wrote:
> Well in a sense a standup is also a status meeting.
> With the difference that the status is for the team.
> Some people don't get that when they start with scrum...

In practice, many teams treat the standup as a status meeting. I've seen
standups that are not status meetings, though. They're collaboration
meetings. Instead of talking about the state of the work, they talk
about the issues surfaced, and others can then offer collaboration.

- George

>
> Scrambled by my Yphone
>
> Op 2-apr.-2013 om 07:45 heeft Dan Rawsthorne

> <dan.raw...@drdansplace.com <mailto:dan.raw...@drdansplace.com>>

> het volgende geschreven:
>
>> Yes, there are no status meetings in scrum. If you have them for some
>> other non-scrum reason, then don't lie.
>> Dan Rawsthorne, PhD, PMP, CST

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

>> On 4/1/2013 10:26 PM, Michael James wrote:
>>> On Apr 1, 2013, at 12:39 PM, Guarino <sofa.k...@gmail.com

>>> <mailto:sofa.k...@gmail.com>> wrote:
>>>
>>>> Also, not sure who said it, but the whole purpose of this is to NOT
>>>> LIE in the status meeting.
>>>
>>> One way to avoid lying in status meetings would be to stop having
>>> status meetings. The meeting that matters to people outside the team
>>> is the Sprint Review Meeting, where we see a potentially shippable
>>> product increment, or not.
>>>
>>> --mj
>>> (Michael)
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Scrum Alliance - transforming the world of work." group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to scrumallianc...@googlegroups.com.
>>> To post to this group, send email to scruma...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Scrum Alliance - transforming the world of work." group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to scrumallianc...@googlegroups.com

>> <mailto:scrumallianc...@googlegroups.com>.

>> To post to this group, send email to scruma...@googlegroups.com

>> <mailto:scruma...@googlegroups.com>.

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

[Yves Hanoulle]

Scrambled by my Yphone

Op 2-apr.-2013 om 20:06 heeft George Dinwiddie
<li...@idiacomputing.com> het volgende geschreven:

> Yves,
>
> On 4/2/13 1:59 AM, Yves Hanoulle wrote:
>> Well in a sense a standup is also a status meeting.
>> With the difference that the status is for the team.
>> Some people don't get that when they start with scrum...
>
> In practice, many teams treat the standup as a status meeting. I've seen standups that are not status meetings, though. They're collaboration meetings. Instead of talking about the state of the work, they talk about the issues surfaced, and others can then offer collaboration.
>

That is Why for me the famous third question is: where do you / I need help?

[Mark Levison]

I don't think you can get a common understanding of what a '2' point story is over a group of 50 or people.

Cheers
Mark

On May 2, 2013 8:23 AM, "Allen Prattis" <apra...@gmail.com> wrote:

Agree that there should be some kind of standardization - and that the teams should be the ones that figure what the standard is.  Reason:

A - forecast (pointed out)

B - for reporting (especially Agile Earned value management)

C - for change - for example if the business wants to add features/change their mind great, but finance needs to understand the financial impact therefore

D - eventually get to a "price per story point" therefore

E - giving business and IT a means to understand the financial impact and additional resources/costs required

F - allow for charge backs within the company (and externally?) for changes and other phases to the projects and 

G - Planning - for example project is 1000 SP, team velocity is 100/sprint, sprint length is 1 month - can do the project in 10 months.

Not really interested in bench marking one team against another, and I am not sure this would make sense.  I would like to accomplish this without "butting into" the good work the feature teams are doing, but this would make the life of the PMT much easier.

Thanks 

On Thursday, March 28, 2013 8:00:45 PM UTC+1, Guarino wrote:

We have approx 15 development teams, some using Kanban, some using Scrum.

Recently we have tried to implement a monthly "Dev Ops" meeting, where teams have approx 5-10 mins to update everyone what is going on.  What projects, what they learned from retros, stating impediments and how they were addressed.

One of the things we show in this meeting is a team wide, then location wide cycle time report.

Since this meeting is a coming together of dev, some managers, some product managers, etc, the concepts of story points and burndowns can be a bit burdensome, so that is why we went with cycle time.

So now, glaringly, the differences in team points has floated to the top of something we "might" want to address.

I am not sure what to ask, so bare with me a bit.  Is there merit in getting all the teams to agree what a 5pt story is?  How do you go about this without saying, "A 5pt story is like 2-3 days".  Most of the conversations end up at this point, and get days assigned to points.  I am trying to stay clear of that, but it seems impossible.

We discussed tshirt sizes, each team would agree that a medium shirt is the "typical" story for that team.  Does that have any merit, never defining how long or how many "story points" the shirt size is worth.

I guess I am looking for ideas, thoughts why it would be good and bad, any information that would help me bring these thoughts to conclusion.  The "business" is skeptical that one teams 13 points is 4 days and another teams is 2 weeks.  Is there anywhere that common ground can be found?  Anyone tackle this sort of thing with success?

Again, this is more of a brainstorming, nobody is mandating it, but does seem in the best interest to find a way that teams can be transparent without showing a burndown chart.

Ideas?

Thanks

[Ron Jeffries]

Hi Allen,

On May 2, 2013, at 5:07 AM, Allen Prattis <apra...@gmail.com> wrote:

A - forecast (pointed out)

Forecasting has to be done on a team-by-team basis and then rolled up. So there is no need for standardization in order to forecast.

B - for reporting (especially Agile Earned value management)

I'm not familiar with the notion of "Agile Earned Value". Despite its name, if this is like ordinary "Earned Value", it is a cost measure, not a value measure. That could be OK but I don't quite see how it's "Agile".

C - for change - for example if the business wants to add features/change their mind great, but finance needs to understand the financial impact therefore

Standard estimates do not help with this as far as I can see. It needs to be done on a team basis and rolled up anyway.

D - eventually get to a "price per story point" therefore

Ah, but this won't work. Stories, points, and the amount of time (therefore cost) to do something is not consistent across teams, and standardizing points will not fix this. If points are standard, teams will not produce the same number of points for the same cost. If points are not standard then you can't do price per story point.

Of course, pricing by value would make more money but no one wants that.

E - giving business and IT a means to understand the financial impact and additional resources/costs required

This is done by roll-up and does not require standard points.

F - allow for charge backs within the company (and externally?) for changes and other phases to the projects and 

Charge backs should be in dollars, not in points. And should use actuals, not estimates.

G - Planning - for example project is 1000 SP, team velocity is 100/sprint, sprint length is 1 month - can do the project in 10 months.

If points are standard across teams, then team velocity will vary by team, and will not be 100 per sprint. Story points are not fungible and multi team projects have dependencies that must be managed. Standardizing story points will not help with this.

To me, these observations add up to "standard points cannot be defined in any useful way".

Ron Jeffries

www.XProgramming.com

Impossible is not a fact. It is an opinion.  -- Muhammad Ali

[Ron Jeffries]

Hi Mark and all,

On May 2, 2013, at 8:28 AM, Mark Levison <ma...@mlevison.com> wrote:

I don't think you can get a common understanding of what a '2' point story is over a group of 50 or people.

I think we should publish a points standardization challenge, which would be for folks who want to standardize points to actually demonstrate mathematically that their schemes will work. We'd set forth a few simple questions, along these lines:

• Define what points mean to you. Be mindful of the original definition, which is a simple linear mapping from time to build to a number or other symbolic measure. Show how your definition compares to that one.
• Define how points are to be calculated for stories. In particular, since you are positing standardization, show how to get these numbers to be standard across individuals, teams, and time.
• For extra credit, exhibit results of experiments showing how well different individuals and teams can use your algorithm to produce standard points.

• Note that different teams will require different amounts of time to do the same set of stories, and that the changes are not linear. One team might do A faster than B, and the other team might do B faster than A. Explain what your standard number means in this case.
• Show how two teams, given the same set of stories, will come up with the same numbers for all the stories. In particular, note that different teams calculating function points do not generally get the same answers. Explain how your approach will not have this same problem.
• Show how, given standard points values, elapsed time can be calculated. Note that different teams will not use the same amount of time for the same numbers of points. Make sure that your algorithm covers this situation.
• Show how, given standard points values, you can calculate the time or cost of a project without knowing which teams will do which stories.
• Show how, given standard points values, you can calculate the time or cost of a project even if you DO know which teams will do which stories. 

Who knows, perhaps someone would come up with something that would work. I have my doubts.

Ron Jeffries

www.XProgramming.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[Mark Levison]

We can write this over a pint of beer  this week.

Cheers

Mark - who woke up so early in Vegas that he's ready for sleep again

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

--
Cheers
Mark Levison
Agile Pain Relief Consulting | Writing
Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24

[Dan Rawsthorne]

I do. Come to my talk at the Scrum Gathering.

Dan Rawsthorne, PhD, PMP, CST
3Back.com

1-855-32-3BACK x323

Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

Good questions. good challenge. I'm finalizing my response in time for the Scrum Gathering, since that's what I'm talking about there.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of Exploring Scrum: the Fundamentals

[Ron Jeffries]

See me there before finalizing your slides. :)

R

On May 2, 2013, at 10:48 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

Good questions. good challenge. I'm finalizing my response in time for the Scrum Gathering, since that's what I'm talking about there.

Ron Jeffries

www.XProgramming.com

Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[Dan Rawsthorne]

I probably will.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of Exploring Scrum: the Fundamentals