--
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.
Derek when you say velocity, I assume you mean actually producing product vs measuring Story points. If you use the Story point measure as a proxy for productivity I can double (or triple) in about 10 minutes.
Cheers
Mark
Hi.
Great stuff so far.
Suggestion since you are down this path for a while.
Ask your customers.
Ask your stakeholders.
Ask your end users.
Ask the teams including ScrumMasters and product owners.
The answers are there.
Mike Vizdos
--
--
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 scrumalliance+unsubscribe@googlegroups.com.
P We have a responsibility to the environment
Before printing this e-mail or any other document, let's ask
ourselves whether we need a hard copy.
26 November, 2012 7:58 AM
Hi MarkI'd be surprised if it took 10 minutes! :)But, here's the thing: If you guesstimated all of your stories up-front and if they weren't subject to 're-estimation' then an increasing velocity is a good measure of increasing productivity.Like any statistic, it's VERY easy to massage velocity to give the appearance of increased productivity but anyone involved with Scrum would spot this a million miles away.--Derek Davidson
From: Mark Levison <ma...@mlevison.com>
Reply-To: <scruma...@googlegroups.com>
Date: Mon, 26 Nov 2012 07:43:03 -0500
To: <scruma...@googlegroups.com>
Subject: Re: [Scrum] How do we calculate ROI for following Agile practices in our projects?Derek when you say velocity, I assume you mean actually producing product vs measuring Story points. If you use the Story point measure as a proxy for productivity I can double (or triple) in about 10 minutes.
Cheers
Mark
--
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.
--
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.
26 November, 2012 7:43 AM
Derek when you say velocity, I assume you mean actually producing product vs measuring Story points. If you use the Story point measure as a proxy for productivity I can double (or triple) in about 10 minutes.
Cheers
Mark
27 November, 2012 2:10 PM
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/t6TR1gUqnlkJ.
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.
26 November, 2012 5:23 AM
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/XUOG7YhZiSUJ.
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/XUOG7YhZiSUJ.
It is a good measure of productivity as long as StoryPoints are about size of the product. A good size metric is functional tests passed, or scenarios releases, or even use cases releases. It is interesting to think about how to measure the size of the delta between product increments. But, since we know we are incrementing the product, there should be some way to measure it, right? That is productivity... how big is the increment delivered each sprint? If you can put numbers on it, this is velocity.
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
Don't understand your comment, but ok. I guess you're saying that since people often use productivity measures for evil purposes, you shouldn't have productivity metrics, and I think I disagree. :)
I don't know what you mean by work, I've seen them work just fine for decades...
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/2FggMkYu8wsJ.
Measuring and tracking velocity, when done correctly, is a valuable tool for answering your team-related questions ("are we improving? are we learning?"). This is the metric for the team to consider... are we doing the thing right, and getting better at it?
She looked at me funny and said "These days around here if you sneeze, you get a story point."
"Inside the team, we don't really need a metric," -Are you making a case that a team does not need metrics?
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
I am not sure you are going to get an answer you want to hear here.
Mike
I have not but I am researching it now, thanks to your suggestion.�Actually reading Dan's presentation on Agile metrics from Agile 2009 conference.�http://agile2009.agilealliance.org/files/session_pdfs/Rawsthorne_AgileMetrics_v6d.pdf
Do you feel it is a better measure of progress than Velocity?
What I am sensing from the anti-story point/velocity camp, admittedly those much smarter than I am, is to not have any metrics. I am not sure I am sold, as, I feel metrics can be used wisely to give clues. I have been researching all day, as, this list always challenges my assumptions, on any studies that show if/how/when metrics hurts/helps performance. I am entirely aware of the danger of misused metrics. I was in IT management for 10 years, and saw it first hand, how the metrics I gathered on a team, with good intentions, produced the wrong outcomes. I took responsibility for it, and removed metrics from my team. My question is to the anti-velocity folks, , are all in process metrics bad? Are there no in process metrics that you believe can help a team? Am I misunderstanding your position?
Thank You,John"Science is organized knowledge. Wisdom is organized life."
�Immanuel Kant
John,
On 11/29/12 6:05 PM, John Miller wrote:
Yes. Delighting customers should be the key metric.
But...my question is, for those organizations who will require a metric.
Outside of velocity, what are the alternatives?
For those that need to understand basic progress for release planning.
If you do not use Velocity, what is the best alternative?
Have you considered RTFs?
- George
--
----------------------------------------------------------------------
�* 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 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.
I have seen velocity used incorrectly. I have seen it used "correctly". I myself used Velocity as a CIO understood the purpose and used it as it intended.
Most organizations, especially larger ones, are not at the hyper trust level to not have team metrics. As one may want push and stretch the organization to this level of trust, not to provide metrics for an organization who requires it may be a sure way for career limiting future. In cases like this, what is the lesser evil or the safest metrics?
But...my question is, for those organizations who will require a metric. Outside of velocity, what are the alternatives?
For those that need to understand basic progress for release planning. If you do not use Velocity, what is the best alternative?
I am not sure about 0 context. I mentioned release planning , which is a pretty common context, especially for organizations where they need to release at a specific time, such as seasonal releases or a big marketing event.
Man, you really have NO Project Manager in you, do you? LOL!
that's too bad. I haven't seen too many that were valid in all their details, but I've seen a lot that were basically sound: these use cases, this date, this team, this cost... and that's what I define as a release plan, basically. The problem is, of course, that you need people who actually believe in yesterday's weather... and I've seen a lot of them in the military.
Hi all,
Very interesting discussion. I would even say a classic.
For me, the big problem is when organizations try to measure the productivity
of software development teams based on the software throughput of the team.
There are many ways of doing it indeed. They all can be useful in some
situations. But not for evaluating team performance.
For me, team throughput or developers productivity is just an intermediate
variable. And one that will never be measured well. It is like trying to
measure the performance of a writer by how many well written pages he writes
per day. The correlation with the potential success of the book is still very
weak.
Every software is used for a reason and brings value to the end user for a
reason. Trying to understand the value generated for the customer and how to
improve it, is much more meaningful as it more directly affects your company
performance.
My conclusion is: Measuring software development productivity (based on
throughput) is most of the time a waste of time. Some exceptions exist.
Example: you are an outsourcing company (and your customer knows very well what
he wants (sounds scary)) and the customer wants to make sure you can deliver
the most functionality per $. In this case, team productivity is a clear
competitive advantage. It might be worth measuring.
Using velocity for the purpose of productivity is a waste of time too whether
it is in story points or function points or whatever. And it is EXTREMELY frustrating
when we try to "sell" Agile to the business. It would be so great to
show before Agile and after Agile numbers with velocity. The fact is that it is
often just not the best way to sell it, in my opinion.
Some Agilists friends told me they used velocity at the team level and that it
contributed to keep the team motivated on using Agile practices as they saw
their own velocity augment. No management involved in this of course. For me, I
could only mean that they improved their Definition of Done. Why not show this
instead?
I think that using velocity in story points is fine for long-term planning.
At least, that is how I use it.
I also think it is of limited value. If you are really
potentially shippable every sprint, velocity is meaningful and usually you do
not wait that much before you release.
The more we feel we need velocity, the longer our releases are. And often it is
because our Definition of Done is very limited.
If you need velocity to plan for more than, say 3-4 months time, it usually means
that you cannot release within 3-4 months and that your ability to release your
product as desired is limited.
In this case, your velocity might well be a meaningless number because
your DoD is so limited. And therefore you need hardening sprints... In
this case: extend your DoD! It is very tough work in many cases but much more
meaningful and rewarding than debating on velocity numbers which can not be
well used.
For me, the main value of story points is that it goes well with release
planning. I had found story points useful for beginners to Agile as it forced
them to break their previous estimation habits which were not team based and
which were often hold as a commitment against them.
If a team works well together, can estimate
and commit together, then any unit is fine for me.
So I am not against velocity nor story points neither. Their usefulness is just much more limited than we think.
To come back to the original question: How do we calculate the ROI for following Agile practices?
I have a question : Why are you using these practices in the first place?
If you are using them to improve productivity, just measure whatever productivity you were measuring before. One of the biggest problems I have seen is people tell me that they want to use Agile methods to improve productivity but they never measured it before…
Any leading indicators (before release) to see the effects of Agile practices are tricky. Probably the best you could use is CFD to visualize your queues (read the Reinertsen book, it is quite good) and expected cycle times.
Some good lagging indicators are: Time-to-market, ROI, customer satisfaction. Normally you should improve on those.
If
you are NOT willing to wait to see the lagging indicators…. Then you probably need to send whoever would like to
see the benefit of Agile practices through leading indicators to a at-least 2
weeks bootcamp training on Agile and Lean product development for managers
(Reinertsen’s book on product development flow is useful for this). After which
they might understand that your evidences of improvement on a few leading
indicators (queues reductions, cycle time reductions, co-location and f2f
communication with customer, faster feedbacks, adaptations after sprint reviews
feedbacks, happier teams etc…) will really make a difference. You cannot
convince with leading indicators people who do not have the right mental models
of what product development is. And unfortunately for us, the vast majority of
our industry still does not. I think this is what it all boils down to. There is no easy answer to this one.
Julien.
"Responding to change over following a plan." That doesn't mean that we shouldn't plan. "Over" is not the same as "instead of."
Ron, you sound very cynical. I tell the people I train and coach that skepticism, a healthy doubt, is good, but cynicism, a refusal to consider, isn't. I can understand skepticism and even cynicism... but if we believe this will never work, then we will be right. Instead, we have to believe that a reasonable plan based on solid data has a reasonable chance, and that we must give up on hope as a valid project management strategy.
"Responding to change over following a plan." That doesn't mean that we shouldn't plan. "Over" is not the same as "instead of." The idea of a release plan is to give the people paying for the project an idea of what is realistic. After all, don't the people paying for a project have the right to some indication as to what they're going to get for their money and how long it's going to take? The reason we track velocity is so we can update the release schedule (# sprints to completion, or what scope will be completed by a desired date) at the end of every sprint, getting a more precise estimate of what we're going to get or how long it's going to take as we go along. If we make changes to the scope, we can see the effect of those changes on the schedule/budget immediately, so that we can get stakeholders to either buy in, or disavow those changes.
Ron, you sound very cynical. I tell the people I train and coach that skepticism, a healthy doubt, is good, but cynicism, a refusal to consider, isn't. I can understand skepticism and even cynicism... but if we believe this will never work, then we will be right. Instead, we have to believe that a reasonable plan based on solid data has a reasonable chance, and that we must give up on hope as a valid project management strategy.
"I've seen a lot of release plans that relied on hope as the primary project management strategy, i.e., BS. I've seen a very few that relied on some underlying data to give a sense of what could be expected based upon the Cone of Uncertainty. I've been very successful on software projects using traditional, task-based project management techniques when the problem domain was well understood, I owned the scope and the resources, and I could set the date after some upfront planning and work breakdown. "
The folks I've trained and coached to successful projects via Scrum are no longer cynical, and increasingly no longer skeptical. Seeing is believing. This stuff works, and it is simple... but not easy.
The people who come here and ask about estimates are not speaking from that kind of successful experience. Frankly, if they were, they wouldn't be asking: they would already know. And estimates are not central to success with Scrum. Yes, the idea does occur in the Scrum Core, and yes, in my opinion, it should be surrounded with barbed wire, caveats, and possibly a moat.The reason is that people beginning with Scrum generally come to it from a more conventional project management outlook, where you just figure out everything that has to be done, estimate it all, add it up, and voila! you have a project plan that you just have to execute. As your experience discovered, that trick only works in quite rare circumstances. As you put it, where you "owned the scope and the resources". In the case of most of our listeners here, that is emphatically not the case.Instead, we find that most of the questions here are about how to improve estimates, so that they will be accurate. When we drill in, we see teams who are projecting when they'll be done and then pushing the teams to complete everything. We see them measuring teams on accuracy. We see product owners who are just doling out the backlog items with little or no control over anything, just "following the plan".
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/_YboqjsVUhoJ.
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/_YboqjsVUhoJ.
The Cone of Uncertainty is a concept, not a physical entity. And, that it is a cone, and not a cloud or amorphous blob, is not an essential property. However, the concept of acknowledging uncertainty and its impact on our projects, and then reducing it via conscious effort is valid.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/JqfofaGkc5AJ.
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/4uyYmdex1NUJ.