• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (5)

1 localhost commented Trackback

Simple metrics like this lead to transparent understanding of what is going on. This type of thinking needs to be expanded to look not only at 'good news' but at all patterns.<div>&nbsp;</div> There are reports that over time tracking of build fails per day in a CI environment quickly shows why 'crashing' a project is more aptly named than the originators imagine. Like any other system a knee exists where additional effort leads to increasingly negative results. Unfortunately the trailing edge of this type of behavior lingers in a program

2 localhost commented Permalink

Hi Scott. I like the idea you've described in the blog entry. We presented the idea to a customer seeking for productivity measures and his answer was: show me money or something I can understand.<div>&nbsp;</div> Well, I know how context sensitive it must be but have you experienced any mapping to "customer acceptable unit" of acceleration?<div>&nbsp;</div> Thanks for your answer.

3 localhost commented Permalink

I just posted http://www.ibm.com/developerworks/blogs/page/ambler?entry=metric_acceleration_examined which addresses the monetization issue. Converting acceleration to $ is really straightforward.<div>&nbsp;</div> What do you mean by "customer acceptable unit" of acceleration? Is it the $ issue?<div>&nbsp;</div> - Scott

4 SelliKondamuri commented Permalink

Hi Scott.. Assuming there is no change in team member size (refer point 6 above), what if the 2-week sprint had 2 public holidays? or 1 of 5 team members was on a week-long vacation? Or, if the team went down from putting an average 11 hrs per day in sprint 2 to a 8 hr per day in sprint 5? Wouldn't calculating Sprint productivity (say, as no. of story points delivered / Total Effort spent on sprint say in person days) be a better way of normalizing instead of only dividing by team size?

5 Xtermist commented Permalink

Hi Scott, <br /> Nice article and I like the idea. But I have a couple of doubts on this <div>&nbsp;</div> 1. Agile principle emphasises on constant pace. The team delivers the same amount of story points on each sprint. If it is fluctuated the team may burn out (by delivering beyond their velocity) or the team is not performing (Wrong story point estimation, unexpected leave, unavailability of right tool at the right time, so and so on can result into such a situation). What is your opinion on this? <div>&nbsp;</div> 2. There will be saturation point where the team attains its maximum velocity. How we can measure the productivity if a team attains that level where there is no room for further improvement in velocity?

Add a Comment Add a Comment