velocity | Scrum Agile Project Management Expert

Velocity is a Lagging Indicator

scrumexpert — Tue, 03 Dec 2024 17:32:00 +0000

Velocity is one a key metrics used by Scrum teams to measure the rate at which an Agile team delivers value to the customer. In his book “Escape Velocity – Better Metrics for Agile Teams”, Doc Norton explains why velocity is not the ideal metric for Scrum teams. In this quote, he explains that Velocity is a lagging indicator. These metrics tend to be weak indicators for the short-term and are much more reliable for confirming long-term trends. Velocity is also a lagging indicator. It is a measure taken at the end of a series of steps. We plan, we prioritize, we work, we test, and then we measure. Lagging indicators are abstract Lagging indicators tend to be aggregate or abstract. They don’t provide detailed insight into the operations, rather they provide an indication of results. Net profit is a lagging indicator for a company. While it tells us about how the company is doing, it gives us no indication of why the organization was or was not successful. Let’s look at another lagging indicator; unemployment. The unemployment index is a lagging indicator. It tells us whether or not unemployment is on the rise or decline, which in turns tells us if the economy is doing poorly or well, respectively. An increase in unemployment means a sagging economy. A decrease in unemployment means a growing economy. But there is nothing about unemployment that tells us why the economy is performing in a particular manner or how we might go about [...]

The post Velocity is a Lagging Indicator first appeared on Scrum Agile Project Management Expert.

Agile Metrics: Velocity is not the Goal

scrumexpert — Tue, 14 Jun 2016 08:35:44 +0000

Velocity is one of the most common metrics used – and one of the most commonly misused – on Scrum and Agile projects. Velocity is simply a measurement of speed in a given direction, the rate at which a team is delivering toward a product release. As with a vehicle en route to a particular destination, increasing the speed may appear to ensure a timely arrival. However, that assumption is dangerous because it ignores the risks with higher speeds. And while it’s easy to increase a vehicle’s speed, where exactly is the accelerator on a software team? This presentation walks you through the Hawthorne Effect and Goodhart’s Law to explain why setting goals for velocity can actually hurt a project’s chances. Take a look at what can negatively impact velocity, ways to stabilize fluctuating velocity, and methods to improve velocity without the risks. Leave with a toolkit of additional metrics that, coupled with velocity, give a better view of the project’s overall health. Video producer: http://oredev.org/

The post Agile Metrics: Velocity is not the Goal first appeared on Scrum Agile Project Management Expert.

Failing Scrum Metrics Programs

scrumexpert — Tue, 03 Nov 2015 15:05:22 +0000

Even if Agile was initially considered as an anarchic approach due to practices like self-organization, the reality is that it requires a lot of discipline. Metrics is an important tool to assess the continuous improvement efforts of Scrum teams. However, setting a good metric program is not obvious. The book “The Agile Culture” contains interesting thoughts about what could make a metrics program fail. Many metrics programs fail and many more do not achieve their intended goals. There are many reasons for this but some of the most common are * Unclear goals and vision of what the organization is trying to achieve. * Misuse of metrics for competitive comparisons or as a punishment rather than a learning process. * Using metrics for political or other purposes rather than using them to help people to do their jobs more effectively and to deliver more value. * Poor communication of the goals and intentions of the program to those involved. * Focusing on process and not results. * Too many metrics leading to lack of focus and ineffectiveness. * Measuring vanity metrics. * Measurements are not timely or the action cycle time is too long. * Poor leadership, which is focused on the metrics process rather than its goals and effect. * Not adapting to the changing needs of the business. Metrics will change over time and you need a mechanism to ensure they remain relevant and effective. If you must have an organizational metrics program, then focus on using it [...]

The post Failing Scrum Metrics Programs first appeared on Scrum Agile Project Management Expert.

Hints for Calculating Velocity in Scrum

scrumexpert — Tue, 27 May 2014 16:09:46 +0000

In Scrum, the velocity is defined as amount of work that the team can handle in one sprint. This is an important measure as it is used to plan the future iterations and to verify that the team is progressing at a constant and comfortable pace. In this blog post, Agile coach Rachel Davies presents a FAQ on how to calculate velocity. The goal of this FAQ is to clear up any confusion about counting team velocity before story prioritisation. The velocity is averaged over the past 3 iterations to level things out. The post suggests answers for important and practical questions like “Should I partially count a story if we did some work on it but it hasn’t been finished?”, “If the story was signed off and complete and then later we discover it has problems, Should we add another story for the extra work to fix it?”, “We had to do some story work in an iteration that wasn’t planned in because the story was not finished from a previous iteration (due to any reason including dependency on other team). What do we do?” or “We did an extra piece of work it took about 2 points worth, it was never planned in or estimated can I count it now because we did do it?”. For each of these questions and some more, Rachel Davies suggests answers that can be use as working agreements on this topic. Read the complete blog post on http://agilecoach.typepad.com/agile-coaching/2014/04/calculating-velocity-faq.html

The post Hints for Calculating Velocity in Scrum first appeared on Scrum Agile Project Management Expert.

Better Predictability with Smaller User Stories

scrumexpert — Mon, 24 Feb 2014 17:31:39 +0000

User stories and their size are often the basis for planning a Sprint in Scrum. You can use a relative estimation and planning poker or a more classical approach to define the effort for each user stories. As such, they are also the basis for the metrics of progress and the velocity of the Scrum team. In this blog post, Doug Brophy presents his opinion that the importance of large user stories in the backlog decrease the reliability of the team velocity (trend) and its usefulness for planning next iterations. The post discusses the “Cone of Uncertainty” (CoU) concept for software development projects that describes the exponentially decreasing uncertainty in project estimates as the project progresses. As Scrum teams will often use something related to a Fibonacci suite to estimate the size of user stories, the larger number is attached to user stories sizes, the wider error margin could exist if we compare the estimate with its “real” size. The article proposes a modified version of the Fibonacci suite: 1,2,3,5,8, 13, 20, 40, 100. The conclusion is that you should “break down your work into as small chunks as is practical. There are many benefits of working with small Agile user stories besides the reduced variability. These advantages include: increased focus, which helps prevent failure; earlier discovery / faster feedback; shorter lead time/ better throughput; and reduced testing overhead.” The blog post is followed by an interesting discussion of this topic in the comments with the participation of George Dinwiddie [...]

The post Better Predictability with Smaller User Stories first appeared on Scrum Agile Project Management Expert.

How to Use Velocity

scrumexpert — Wed, 28 Aug 2013 16:26:43 +0000

Velocity can be defined as a measurement of how much the Scrum team can get done in a Sprint, based on past results. In this article, Beth Macy discusses how reliable is velocity and how you can use it. He starts by defining that “If a team is kept intact for approximately three months and on the same project for that period of time, then its velocity will stabilize within a range and be predictable for the duration of the project.” There are many factors that impact velocity like the size of the Scrum team, the project complexity or an uninvolved product owner. Then he discusses how you can use team and individual velocity. His conclusion is that team and individual velocity are useful metrics. However, they should be used with caution and only for the good of the team and the project. Read the complete article on http://www.scrumalliance.org/community/articles/2013/2013-april/how-should-we-use-velocity

The post How to Use Velocity first appeared on Scrum Agile Project Management Expert.

Sustainable Pace in Agile Teams

scrumexpert — Fri, 22 Jun 2012 16:41:40 +0000

We would like solutions delivered fast without compromising quality, user experience, implicit requirements and non-functional aspects such as scalability and performance. This would have been easier, if we had all the time in the universe. Doing this in a sustainable manner becomes a huge challenge for teams as there are multiple competing forces at play and because software development is very complex. [youtube LgvnhuyCYuc] Video producer: Agile India Conference

The post Sustainable Pace in Agile Teams first appeared on Scrum Agile Project Management Expert.

Understanding the Scrum Burndown Chart

scrumexpert — Mon, 06 Feb 2012 15:43:45 +0000

The Scrum Burndown chart is very simple tool to monitor the project status. It is easy to explain, easy to understand. But this metric also put in evidence some pitfalls observed in many agile workshops and adoptions. This article discusses how to build a Scrum burndown chart and what should be included in it. It also presents guidelines on how to assess the project status using the burndown chart and what could be done when problems are detected.

The post Understanding the Scrum Burndown Chart first appeared on Scrum Agile Project Management Expert.

Shock Therapy for Scrum

scrumexpert — Fri, 20 Jan 2012 16:51:27 +0000

When properly implemented, the Scrum framework enforces simple constraints that lead a team to self-organize into a state that achieves 5 to 10 times performance improvement versus traditional approaches. However, the majority of Scrum teams is unable achieve this objective. Teams do not know how to sequence work to deliver working software at the end of a sprint. They do not know how to work with a Product Owner to get the backlog in a ready state before bringing it into a sprint and do not know how to self-organize into a hyper-productive state during a sprint. A pattern is emerging in organizations to bootstrap high performing Scrum teams. Rigorous implementation of Scrum by an experienced coach creates a total immersion experience akin to Shock Therapy. Teams are trained on exactly how to implement Scrum with no deviations for several sprints. These teams consistently achieve better than 240% improvement in velocity within a few weeks. They are then able to self-organize on their own to continue to improve performance. For many developers and managers, the experience is a wake up call to agile awareness. Unfortunately, management tends to disrupt hyperproductive teams by disabling key constraints in the Scrum framework. Team velocity then falls back into mediocrity. Velocity data was provided in this article by five hyper-productive teams in two companies. In all but one case, management “killed the golden goose.”

The post Shock Therapy for Scrum first appeared on Scrum Agile Project Management Expert.

The Danger of Velocity

scrumexpert — Wed, 16 Nov 2011 08:58:57 +0000

Velocity is killing agility is the observation discussed by Jim Highsmith in this blog post. He explains that this metric is increasingly used for the wrong reasons: measuring productivity and focusing on volume delivery instead than on quality. He concludes saying that the importance given to velocity should be balanced with other metrics like feature value, feature delivery cycle time or quality.

The post The Danger of Velocity first appeared on Scrum Agile Project Management Expert.