Skip to content

Category: velocitySyndicate content

Measuring velocity is not enough to determine team productivity

June 20, 2009 by Jack Milunsky

Introduction

Another interesting question was brought up in a LinkedIn discussion thread this week: "Is velocity the right approach to measure productivity of team members working in Scrum. If not, then how can productivity of team members be measured in Scrum?" Here are my thought on this topic.

The purpose of velocity

Like burndown charts, velocity is just another metric which the team can use to reach what I believe is the ultimate goal – sustainable throughput. Velocity in my opinion, is not a metric for determining productivity. Productivity or team efficiency is difficult to measure and probably best left for another blog post.

The significance of Story points

March 20, 2009 by Jack Milunsky

Expecting your teams to estimate in Story Points can be quite a leap of faith. When I first introduced the concept of Story Points at my previous company no-one could wrap their heads around the concept. When it comes to estimating, we’re so accustomed to thinking in days or hours that making the leap to some obscure, seemingly illogical measurement is quite the expectation – especially a bunch of engineers.

Getting used to it
Once you start using Story Points, it usually only takes a couple of sprints before teams start to understand the magic in this new practice.


Accounting for bugs the agile way - part II

March 6, 2009 by Jack Milunsky


Last weeks post struck a cord with readers and as a result I got some really good feedback. Based on the responses I decided to use this week's spot to clarify my position on some of the issues as I see them.

I believe that ...

1. Teams should do whatever they can to fix bugs that are found during the sprint in which they're found. The definition of "Done" means the feature is coded to standards, unit tested, functionally tested, documented and all known bugs are resolved during the sprint. If you postpone bugs, what seems trivial at first will mean significant build up of technical debt which you will need to pay for downstream.

How We Actually do it: Accounting for Bugs in an Agile World

February 27, 2009 by Jack Milunsky


Today I'd like to share with you a really important aspect of Agile software development - how to account for bugs in your daily plans.

I am frequently asked by teams I consult with how to deal with bugs if you're Agile and using Scrum. Questions like the following come up time and time again:

"Should I track hours burned fixing bugs?"
"Should the hours burned on fixing bugs count toward my Story Point velocity?"
"When do you schedule bugs and should this be done during Sprint planning?"

You Need to Account For Bugs

My company is often working on many simultaneous projects and having to juggle resources. To get everything done on time and bug free requires careful planning. As a result we have to ensure that we're considering all aspects of software development including bug fixing. Bottom line is Bugs take time to fix and so you have to account for them. If you don't, you will have an inaccurate measure of your teams productivity - something that will definitely lead to poor planning and late deliveries. (....read more)

Predicting the team's Velocity: yesterday's weather method

September 25, 2008 by Przemysław Bielicki


Picture courtesy of aloriel@flickr

"How much software will you deliver in the next Sprints/iterations?" - do you often hear such questions? I do. And this question is really valuable especially for the project/product sponsors. But not only management likes knowing how much software they will deliver in the upcoming Sprints. Everybody (including development team members) likes to know the answer for questions like: "Where we will be in three months from now?".

If you track your team's Velocity you are able to answer such questions somewhat accurately, which is great. I personally don't know better tool for answering presented questions than tracking development team's Velocity.

Let me now explain how you can compute how much software your team will deliver in the next Sprints basing on the current team's Velocity.

Fooling Myself with False Velocity

April 21, 2008 by JurgenAppelo

Writing2I'm an idiot, I have fooled myself. I'm usually quite good at fooling others, but this time I have fooled myself. And I did it with what I might call a false velocity.

Velocity Defined
Velocity is the rate at which you complete your work, in a certain period of time. This might refer to the number of stories completed, the number of issues processed, the number of exams passed, the number of kilometers driven, the number of hamburgers baked and served, or (for some guy I know) the number of girls dated and dumped.

The Velocity of Writing a Book
I might have mentioned earlier that I'm trying to write a book. It's a book about managing software development, and the things we can learn from complexity science. Last year I did a lot of research, a tremendous effort that will continue to the end of this year. And I started writing my first pages of text in January this year. I am planning to write around 350 pages in 1.5 years, which equals to an average of 5 pages per week. After 15 weeks I have completed 75 pages of text, which is... 5 pages per week! It's exactly the velocity I need to finish the book as scheduled. Right?

Velocity: Measuring and Planning an Agile Project

December 10, 2007 by Jeremy Weiskotten


Bridgekeeper: “What is the velocity of an unladen swallow?”
King Arthur: “An African or European swallow?”
Bridgekeeper: “Huh? I don’t know that…”

- Monty Python and the Holy Grail

One of the most important metrics of an Agile team is its velocity. (No, you don't have to give the receptionist a stopwatch and do laps around your office.) In project management terms, velocity is the amount of work that a team can complete in a specified period of time.

Unfinished work

November 21, 2007 by Artem Marchenko

half iPod

Agile processes recognize and try to effectively use the fact, that software creation is a difficult and not very predictable process. Therefore quite often teams applying agile processes end up with the not completing all the committed product backlog items by the iteration end. Teams just starting to employ Scrum or XP can sometimes end up with half of the items being not completely done. Naturally in such a situation people are tempted to finish the uncompleted stuff as soon as possible. Some think about extending the iteration length for a week or two, some think about marking the item half-done, adding half of its size to the team velocity and continuing with it during the next iteration.

Measures of size

December 11, 2006 by Artem

Measurement is fundamental to any engineering discipline and the planning of a software creation work is no different. Whenever you plan to make or renew a piece of software the most important metric as the workload size. Measure of size is important because knowing the amount of work to do and the team skills (i.e. velocity) you can easily derive the work costs and duration. Agile software development methods do strive against the overplanning and overdetalization.

Best of AgileSoftwareDevelopment.com