Two Agile teams start working on Application A, at the same time developing exactly same functionality. Team 1 delivers with a constant velocity…
While searching on the internet about AgileEVP (Agile Earned Value Management) I came across a formula from my high school physics: v=d/t, the Average Velocity formula. I really enjoyed high school math, physics, and its exams: Two trains leave Station A at the same time traveling in the same direction, Train 1 travels with a constant velocity…
Here is the formula that got me started:
High School Physics Average Velocity
The average velocity v of an object moving through a displacement (d) during a time interval (t) is described by the formula: v=d/t
where,
v = Average Velocity
d = displacement
t = time
Exercise 1:
What is the average velocity for a car with a displacement of 120 km in the interval of 3 hours?
V = d/t, where d is 120 km and t is 3 h
Solution:
V = 120 km / 3 h = 40 km/h
Average velocity: 40 km/h (the car average velocity is 40 kilometers per hour)
So I decided to compare high school physics average velocity with team average velocity as an Agile development concept.
Typical Agile projects use iteration fixed in time, so instead of t, team average velocity uses the number of iterations as the time variable.
Displacement in Agile is measured by means of story points completed.
Velocity, in Agile, team velocity, means the number of story points the team completed in the Iteration.
Agile Team Average Velocity
The average velocity v of a team delivering story points (s) during the iterations interval (i) is described by the formula: v=s/i
where,
v = Average Velocity
s = story points completed
i = the number of iterations
Consider sp for Story point unit, it for iteration unit, and sp/it as velocity unit (Story points per iteration)
Exercise 2:
What is the average velocity of a team with a completion of 120 sp in the interval of 3 it?
V = s/i, where s is 120 sp and i is 3 it
Solution:
V= 120 sp / 3 it = 40 sp/it
Average velocity: 40 sp/it (the team average velocity is 40 story points per iteration)
Agile projects extensively rely on the concept of average velocity. Average velocity is very useful for agile team planning activities such as iteration and release planning. For example, my team is about to have an IPM (Iteration Planning Meeting) and we had to decide the number of story points to sign up for the next Iteration. The Average velocity from the last 3 iterations is a good initial value for the team to go about signing up for work for the coming iteration.
Posts
12 comments:
You have to be careful with average velocity. I've been on projects where people panic because the average velocity makes the project look like it is failing. The problem with average velocity is that there are always outliers, usually from the first few iterations, that skew the average. For example if you have the following velocities for the first 7 iterations (0,5,14,23,26,32,23) your average velocity is 17. But if you remove the outliers (0,5,14) your velocity is 26. Using an average without trimming is IMO a bad idea.
I agree with you. I typically use the average Velocity as a basis for the future commitments. But as you said, using the average Velocity without trimming is not a good idea.
This is why people use other statistics for this sort of thing.
Some people like sum of squares/euclidian distance (for your example, 20), or median (23).
Another is a to give more weight to later iterations. All else being equal (All else is never equal), the next iteration should look more like the last several than like the ones before it.
This I think is especially true because people revise their 'unit of work' over time, based on past experience, and, most importantly, expectations. It's very difficult to measure things when people know they're being measured. If you place too much emphasis on the measuring (measuring becomes judging), you get metric dysfunction. I don't think I have to tell you how much worse that situation is than flying blind, but trust me, it is very much worse.
I too have suffered from a variability in Velocity (commonly at the early and late stages of a project) and certainly find averages useful.
It is possible to alter the 'variability' in velocity by altering the size of your stories, the length of your iterations, the amount of time you work and of course your estimating ability. I posted some simple analysis on this and for example you would need to both double your iteration length and halve your story size to reduce variability by 50%.
Hey Fred,
Thanks for the comment.
My next blog post ( the team acceleration concept ) provides a way to measure variability in Velocity. I found agile acceleration useful for forecasting (or at least trying to) the velocity for teams in early stage of a project.
Your entry on ( “Volatility of Velocity” very good. It is interesting to see the statistics formulas applied to the day to day Agile concept such as iteration length and story size.
Cheers,
Paulo
I can see that you are an expert at your field! I am launching a website soon, and your information will be very useful for me. Thanks for all your help and wishing you all the success in your business. Please come visit my site Speech Pathology and give me any valuable feedbacks.
I noticed that in my daughter's school teachers are using this program to help them in their stuff and I've seen that it is excellent. Viagra Online Generic Viagra Viagra
My all queries regarding this subject have satisfied by reading your blog and I was looking such intellectual information for long time.
Regards
Viagra Online
Average velocity and speed both concepts are used in day to day life physics while driving.
Domain and Range of a Function
Hey thank you. very simply explained doubt are cleared.
Regards,
elliot thomas
buy online viagra generic usa
Thanks mate for such informative blog. Reading this my all queries got solved. Thanks and keep posting such blogs.
Regards,
Etizolam Tablets
Post a Comment