Agile Velocity is an extremely simple method for measuring the rate at which scrum teams consistently deliver business value. In other words – How much product backlog effort a team can handle in one sprint? It’s the rate at which a team delivers stories from the product backlog, i.e. sum of estimates of delivered (i.e., accepted) features per iteration. It can be measured in story points, days, ideal days, or hours that the Scrum team delivers – all of which are considered acceptable.
A team delivers 20 and 30 story points in the first & second iteration respectively. The average velocity = Sum of Story points delivered / Number of iterations = (20 + 30)/2 = 25 Story points!
- Only the aggregate velocity of the team matters, and the phrase “individual velocity” is meaningless.
- Velocity is NOT productivity. Instead of a speedometer, it is more like a measurement of a team’s rhythm and should be used to monitor team health.
The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.
- Reporting, i.e. how much value is delivered (Story points/User stories)
- Resource and project planning (timelines)
- Adjusting project scope and business priorities, and forecasting release dates
- Identifying and removing obstacles that affect velocity
Do not try to over-complicate velocity – it really is a straight forward concept and a great deal of its value lies in its inherent simplicity.
Sanjeev Batta | Agile Practitioner and Coach, Entrepreneur ( CSM, LeSS certified )
Velocity if measured in principle can be a complex metric. A lots of time I see teams confuse speed with velocity. Speed is going fast, velocity is more along the lines of are you getting closer to the goal of business value. Just because you are delivering user stories, does mean you have high velocity. Are the stories aligned well with business value, did you learn something during retrospectives or customer demos that negates the work done or are you accumulating technical or other debt by postponing risk to a later stage. Getting too invested or carried away in any metric and following it meaninglessly just creates false sense of progress defeats the spirit of agile. I use metrics as a guide and a gauge not as way to drive project or measure teams success.
Jason Buksh | Head of QA at London Stock Exchange. Enabling delivery capability
I would consider ‘number of outstanding defects’ also ‘business features delivered’ … not quite Scrum Metrics, but velocity on its own may not provide enough context depending on its implementation.
Thanks for the inputs Jason ? Feels good when a QA Head involves in quality discussions.
- ‘Business features’ ?
- Outstanding defects or complete defects metrics including defects identified-fixed-outstanding-etc?
- How about Burndown/up chart..any usefulness?
Allen Woods | Structured coherent information management…
Your proposition is so full of flaws its just not real. You seem to be assuming that completing a story point (and there is a misnomer if ever there was one), does not require rework. Lets assume that there is some rework, your velocity calculations are bound to be skewed by virtue of the rework effort. Rework is further complicated by things like Agile article 2 which reduces the emphasis on documentation. If you reduce documentation, rework becomes harder.
Agility in software development, does not come from meeting artificial targets like “meeting this or that story point”, it comes from having an architecture in which there is a robust, architecturally sound object repository in which scope and in particular encapsulation, for objects is well defined and carefully documented. I wonder if anyone else has read things like “The Mythical Man Month”?
And no, I am no lover of the Agile/Scrum mix. Amongst other things, daily scrum sessions are expensive, but also imply that developers nowadays have the attention span of a gnat.
We also discovered about 20 years ago, the hard way, that artificial measure of code production, like “lines of code” were or other forms of way point scoring were flawed in that they imply that every coding problem can be solved by the same amount of development effort. So untrue its not real. And lets try and put that into perspective.. In the server version of MS Project, there is a “back” button, the aim of which is to provide a robust way if rolling back project status and at the same time track and otherwise adjust cross project dependencies. I am given to understand that that single back button has 400k lines of code underneath it. Now that is an extreme sample, but the reason for raising it is that quite simply, when developing something complex, you don’t know and cannot know, which particular problem will cause extended grief..
Hiya, there is no one “best” methodology. There is what works. And if agile rocks your boat, then fine, crack on. But the nature of problem solving, in terms of writing code, is way to diverse to make it something that is easily measured. Lets put it this way… I am a Chartered Member of the British Computer Society etc., I have been writing code for nearly 30 years now. but.. most of my work has centered on UK Defense Logistics. I would be next to useless in banking for example because I do not know how banking works. Programming methodology would not change that, not one jot.
For software projects to succeed, there needs to be a rare combination of capabilities, the first, of course, being able to code, the second, equally as important, is understanding the business. The third, vital, is to understand your development architecture. If you take an alternative to waterfall, IBM’s “V” model, it, when you study it, is geared towards the IBM prouct architecture (sign up to www.jazz.net), but they have spent some time and much treasure, buying things like COGNOS, DOORS etc and integrating them into the “V” model so that they have an end to end product architecture. The net effect is a considerable degree of agility IF, stress if, you have access to the full IBM product set and know how to use their object frameworks.
The same is true of Microsoft. They have an object library, into which, pretty much all of their product catalog has been integrated via the .NET framework. To my mind, something so useful, its just not real once you understand how MS do their architectural design. Its only when you know that kind of thing that something like “Agile” starts to make sense. The same applies to Oracle. Agile/SCRUM works when you have highly skilled people who know the architecture they are working on, intimately and really understand the nature of the problems they are trying to address. It is not the method per se.
And its not an issue with “Agile” either.. The same can be said for SSADM, Jackons Structures, PRINCE, TOGAF and a whole host of other things beside. They work when they work.. But there are no silver bullets.
Sorry, but if your start point is the manifesto, as opposed to structured design, then you are bimbling, ultimately. But like I say, there are no methodological sliver bullets given the diversity of the software development task nowadays. If it rocks your boat, go with it. But not on anything safety critical or similarly risky..
Allen, I think the whole point of modern day “agile” is to engage the technical personnel to learn the domain knowledge of which these systems are coupled together. The days to create systems to match a business are mostly long gone. Most come into a company to understand, support, and revise existing assets to meet a business goal. Without that domain/industrial knowledge. Zachmann gave a great lecture via BCS, and I loved it. Cos he hit the nail on the head. You cannot create something when you do not know what it is supposed to be for. The driver of the creation comes from the business side.
Though, I do think that Jason, and also Deepanshu could benefit in knowing some EA principles, as to realize how to configure or to adapt a system more easily to the business conceptual layer. At least it will reduce the numerous reiteration of agile cycle…. or “sprint”, as it is classed as.
Allen Woods | Structured coherent information management
May, unfortunately, information management seems, from time to time, to attract enthusiasm for this or that particular technique that borders on religious fervor. My first experience of that was in the late 80’s early 90’s over which OS was best. There are endless (almost) skirmishes in the programming world over which programming language is “best”. There is only what works in any given situation. What irks about Agile is that it (the manifesto) clearly states a preference for coding and delivery over “planning” and documentation. and that is a nonsense. Not least because it generates problems down stream.
And as for daily SCRUM tree hugging sessions. Someone is paying for that and usually it is a hidden cost. Once people start to realize that getting 20 “experts” in a rom at whatever per diem rate it adds up to, is being lost, every day, then SCRUM will be seen to be what it is, one of the more inefficient project management regimes there is.
And in any event, what on earth makes people think that someone trained in any project management technique can “lead” a technical project of any kind. Project Management is, by definition, about “management”, that is to say co-ordination. Not at all about that mythical concept “leadership”. The combination, on anything complicated, is the blind leading the blinded… Not smart.
Marcelo Lopez, AKT, CSP-SM, CSP-PO, CSM, CSPO | Leading through serving
Only because people don’t have a good handle on what a strong definition of done is especially in safety-critical situations like medical devices but it can be done. The point is people don’t consider that that is something that is done in conjunction to the things that a scrum team would be doing.
I’m sorry if people think that you can’t be agile and have a safety-critical situation product project or program. My suspicion is that they don’t have a real understanding of what being empirical and therefore agile thinking really is about and then applying strong and Sound Engineering practices around that agility.