Is velocity the right thing to track team producitivity?
Paulo Roberto V. Camara
[]s,
Paulo Camara
Ron Jeffries
wrote:
> How are you guys measuring teams' productivity working with Scrum? Is
> velocity the right approach? If not, what are you doing?
What does "productivity" mean to you? If you could measure
productivity, what would that mean to you?
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning. --Albert Einstein
Paulo Roberto V. Camara
[]s,
Paulo
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
Dan Rawsthorne
and Hours/SP (or $/SP) and some measure of Business Value. The latter is
hard to measure, and you'd have to get the values from the business, but
something like increased sales for this release, or money made with
latest version, whatever... This last is the ultimate measure of
productivity from the business's POV, but the first two are things you
can measure down at the team level.
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
d...@danube.com, 425-269-8628
Ilja Preuß
Curious, Ilja
2009/12/22, Paulo Roberto V. Camara <prob...@ciandt.com>:
>> scrumallianc...@googlegroups.com<scrumalliance%2Bunsu...@googlegroups.com>
Dan Rawsthorne
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
d...@danube.com, 425-269-8628
Ilja Preuß
use would invoke a different answer. That's why I'd like to know what
Paulo would use it for.
Cheers, Ilja
2009/12/22, Dan Rawsthorne <d...@danube.com>:
Mark
- but I try to think what my management might ask as I try to promote
agile development in our non-agile company. They might want to be able
to compare productivity of teams using agile against ones not - or
against some historic data for past projects. There are also many
presentations on the web touting the benefits of agile over waterfall
and talk about better productivity, hyperproductivity (Jeff
Sutterland's Google talk comes to mind with type-C scrum). I also see
surveys of projects from 2001 (talking about % of features never used,
and the like) used to compare to current trends in scrum/agile. All
this, in some way, ties into productivity. Of course, what
productivity means is still a question, right? If your team is
producing X number of FP's of code per day and X is higher than any
other recorded team but the applications are useless to the customer,
then who cares about productivity in that sense. You've failed to
deliver value - albeit, very efficiently. So, it seems that some
measure of dollars spent against a somewhat hard to measure "level of
customer satisfaction" would be the best measurement. But the "level
of satisfaction" number would be hard to come by in a consistent
manner so comparisons between teams/organizations would be nearly
impossible.
Just my 2 cents,
Mark
On Dec 22, 5:08 pm, Ilja Preuß <iljapre...@googlemail.com> wrote:
> I can think of a whole bunch of thinks it could be used for, and every
> use would invoke a different answer. That's why I'd like to know what
> Paulo would use it for.
>
> Cheers, Ilja
>
> 2009/12/22, Dan Rawsthorne <d...@danube.com>:
>
> > Probably to do future release planning, is what I'd use it for.
>
> > Dan Rawsthorne, PhD, CST
> > Senior Coach, Danube Technologies
> > d...@danube.com, 425-269-8628
>
> > Ilja Preuß wrote:
> >> What would you use that knowledge for?
>
> >> Curious, Ilja
>
> >> 2009/12/22, Paulo Roberto V. Camara <probe...@ciandt.com>:
>
> >>> How much work the team is getting done over the time.
>
> >>> []s,
>
> >>> Paulo
>
> >>> On Tue, Dec 22, 2009 at 5:15 PM, Ron Jeffries <ronjeffr...@acm.org>
Peter Hundermark, CSC, CST
On Dec 22, 10:05 pm, Dan Rawsthorne <d...@danube.com> wrote:
> Probably to do future release planning, is what I'd use it for.
In the case you suggest I would choose the word "predictability" to
describe both what I was trying to measure and and (essentially) what
I was trying to achieve in planning future releases. And I probably
would use velocity as my primary metric.
Yet I would suggest that Ron's and Ilja's questions are important.
care in understanding the motivation for and the use of metrics are
critical if we are serious in our intent to allow the system
(including the people in it) to organise itself. In Scrum I would
suggest we are serious about this.
And I would suggest further we should not ignore Martin Fowler's
observations (http://martinfowler.com/bliki/
CannotMeasureProductivity.html).
So I remain, with Ron and Ilja, curious to understand better the
problem that Paulo wishes to solve.
Peter
Peter Hundermark, CSC, CST
On Dec 23, 2:11 am, Mark <markpetro...@gmail.com> wrote:
>... but the applications are useless to the customer,
> then who cares about productivity in that sense. You've failed to
> deliver value - albeit, very efficiently.
Spot on!
> So, it seems that some
> measure of dollars spent against a somewhat hard to measure "level of
> customer satisfaction" would be the best measurement. But the "level
> of satisfaction" number would be hard to come by in a consistent
> manner so comparisons between teams/organizations would be nearly
> impossible.
In my experience simple, well-constructed surveys of customer
satisfaction and of team-member satisfaction can yield a surprisingly
good amount of information about the value created by (Agile) teams
and their own satisfaction with their way or working. Doing this from
time to time can give you a baseline and a trend. More importantly it
gives you something useful to talk about within your team(s) and with
your customer.
Peter
Paulo Roberto V. Camara
1) As people already mentioned, to do future release planning.
2) To set internal benchmarks in order to challenge the team to work better.
3) To sell Agile benefits to our customers, so they can compare this approach with other ones.
4) To evaluate and drive the effectiveness of continuous improvement actions and investments.
5) To correlate with other metrics related to quality, team and customer satisfaction, value delivered, etc in order to understand how productivity is affected by them and how it affects them.
Probably there are more, but I couldn't remember now by heart.
When I look at velocity, it fits very well for item 1. For the other aspects, I see some drawbacks as the velocity is intimately related to each team, as it is based on what that particular team consider a story point. So it is complex to compare different teams and even more tough to compare with other approaches where do not exist the concept of story point.
What do you think?
Ron Jeffries
you wrote:
> 1) As people already mentioned, to do future release planning.
> 2) To set internal benchmarks in order to challenge the team to work better.
Wrong. External challenges don't work. Comparisons to other teams
don't work: neither team nor problem is comparable.
> 3) To sell Agile benefits to our customers, so they can compare this
> approach with other ones.
Comparisons with other teams still don't work.
> 4) To evaluate and drive the effectiveness of continuous improvement actions
> and investments.
Inside the team, you'll know. Outside ...
> 5) To correlate with other metrics related to quality, team and customer
> satisfaction, value delivered, etc in order to understand how productivity
> is affected by them and how it affects them.
Please explain.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Each of you is perfect the way you are ...
and you can use a little improvement. -- Suzuki Roshi
Ilja Preuß
> I would use this information for a lot of things:
>
> 1) As people already mentioned, to do future release planning.
The best way I know to do that is using some variant of story points
plus yesterday's weather.
> 2) To set internal benchmarks in order to challenge the team to work better.
This sounds quite dysfunctional to me. There are many reasons why
different teams, on different projects would have different
velocities, no matter how you measure that. If you want your teams to
work better, I'd advice to not put them in competition to each other,
but to build a culture where it's possible and safe to learn from each
other, to do experiments, and where the teams feel supported by
management in their quest to do better work.
> 3) To sell Agile benefits to our customers, so they can compare this
> approach with other ones.
To do that, you are asking the wrong people. Ask your customers what
they care about. You might also find that giving them numbers doesn't
do as much to help selling to them as you might hope.
> 4) To evaluate and drive the effectiveness of continuous improvement actions
> and investments.
If you want to improve, you first have to decide what you want to
improve. Then measure that. Again, we are the wrong people to ask.
> 5) To correlate with other metrics related to quality, team and customer
> satisfaction, value delivered, etc in order to understand how productivity
> is affected by them and how it affects them.
Again, I'd think you'd have to first decide what you actually care
about before you can decide on a metric. Or quite possibly several
metrics.
And always keep in mind that with a complex activity like software
development, it's really impossible to measure everything that's
important.
> When I look at velocity, it fits very well for item 1. For the other
> aspects, I see some drawbacks as the velocity is intimately related to each
> team, as it is based on what that particular team consider a story point. So
> it is complex to compare different teams and even more tough to compare with
> other approaches where do not exist the concept of story point.
>
> What do you think?
I think it is impossible to objectively compare teams, no matter how
hard you try to do it.
I also don't think that it's necessary. Probably even dangerously
misleading and likely to lead to dysfunction.
Cheers, Ilja
Jason
that is the intent of velocity either. I use it only to put the thumb
in the air about what range of stuff the team can deliver and roughly
when they could deliver it.
I honestly don't know what is the best way to track productivity of a
Scrum team but some of the questions I ask relate more to whether or
not the team is delivering business value. While I really don't like
that canned "agile teams are all about delivering value" response,
here's some specifics that are in no way shape or form scientific:
- is the PO happy? are end users happy?
- are customers reporting the same problems over and over again?
- how quickly is the team turning around client requests?
- are we plotting revenue against what we thought had business value
to see if we really are delivering value?
- what's the team's energy level like? do they love coming to work or
is it just a job to them?
On Dec 22, 12:47 pm, "Paulo Roberto V. Camara" <probe...@ciandt.com>
wrote: