Ways to improve velocity

Is there team retrospective? What's the impediments that stop the team'? I think you should focus on outcome rather than output

I have seen reports of velocity being relatively constant, while the team actually did improve in the rate of delivering value. The explanation was that the team unconsciously adapted the estimation metric to their better performance.

If this is the case in your situation it would be a good idea to be transparent about it as well.

> I've challenged my team this year to increase our velocity
[...]
> The organization wants us to go faster

Velocity can be increased tenfold by multiplying story points by ten. Agile teams and their organizations don't go faster by increasing velocity. They go faster by deploying increments into production more frequently so as to minimize depreciation and the cost of delay.

The Product Owner is accountable to stakeholders for the release of value, ROI, and the rate at which business value is delivered. So, is it actually the PO who is demanding more frequent releases into production? Is continuous integration and deployment already in place? What does the PO have to say about release frequency?

it's not a matter of more frequent releases. This is a greenfield project. It's broken down into 4 major releases. The organization (starting with our CEO) would like those releases to be completed in a shorter time frame. So, yes, the Product Owner also wants that. The faster I get something into the hands of our customers the faster we can start selling the product (and realizing the value of the investment).

Continuous integration is in place. Fully automated unit and UI test suites in place for continual feedback.

Arguably, velocity isn't increased by multiplying all PBIs by 10 because your burn-up rate remains exactly the same...the numbers just become bigger. No differently than a reverse stock-split. In the end, its all the same.

So, what I'm really looking for is a way to increase our burn-up rate (which in my experience is typically called velocity). We actively manage our backlog so that we are taking on the highest valued or highest risk items first. Nonetheless, this is not a website where I'm "releasing" to customers every sprint. This is a highly complex engineering application that has multiple sprints planned before we'll have functionality that can be released to a customer. Getting the amount of work, or value, completed in those sprints faster will bring in our release schedule, which will provide for a faster ROI.

Why not remove the notion of velocity and estimate to improve the team productivity.

Let me make sure I understand.

Don't worry about velocity and estimates going forward. Disregard those statistics. Velocity is not something that the individual developers spend any time on, so ignoring it won't really improve their productivity. Arguably it's possible we gain some productivity just removing the thought of.

They certainly spend time estimating, which is a primary outcome of sprint planning. I'm confused how one plans for the correct amount of sprint content if they don't have estimates.

But, let's go with that. No velocity and no estimates (if I read the response correctly).

Now, my organization asks me next month "How are things going? Are you still on schedule and budget?" But, without estimates I can't tell them how much is left to release and without velocity I can't tell them how fast we're going, so I have no release date. My response could be "Thanks for the investment, but I can't tell you when we'll be done or how much it will cost. Keep the money coming."

Now, put yourself in the shoes of your investor (your CEO). You're no longer working on a project for your company. You're pitching a great idea to a group of investors (think Shark Tank) and battling for a limited set of investment dollars (which is what you're doing inside of an organization, whether you realize it or not). How well will your project be received if your request for a $10M investment is "I don't know when it will be done, so I don't know when it will start generating revenue and I really don't know if the $10M I'm asking for will be enough, because I haven't spent any time estimating the size of the project." Wanna guess at your chances of receiving those investment dollars? Extremely close to 0%.

I hear this all the time, primarily from consultants that really have very little skin in the game when it comes the success or failure of a project (like it or not...success is primarily defined as on schedule and on budget). Don't worry about velocity. Stop estimating. Just do your work, provide value and all will go well. Yet, as one who's managed multiple multi-million $ software projects I've yet to see a single organization that isn't interested in when their investment will start to show a return. And, to report that, you need to know how fast you're burning $s as compared to how fast you're getting work done towards a release.

Knowing what's left and how fast we're burning down the pile of what's left creates some incredible discussions on our team. It helps us prioritize, it helps us determine how far to take specific features, it helps us determine what we can live without, it helps us determine what can be added, etc.

> Now, my organization asks me next month
> "How are things going? Are you still on schedule and budget?"

In Scrum the question is redundant, because by next month an increment of working product *must* have been delivered. The Product Owner will be in a position to release it and to account to stakeholders for value and ROI.

In Scrum the sole measure of productivity is the delivery of working software...not promissary notes about being on schedule or on budget.

Ultimately it really is about having more frequent releases. Estimates and velocity are simply tools that Scrum Teams use to forecast how much work can be taken on in a Sprint. The more frequently a team releases value, the less important forecasting becomes.

Too idealistic.

As I stated, this is a greenfield project. Let's say, for example, I'm developing a product to compete with MS Excel. I'm guessing there are quite a few lines of code in Excel. I have 1 month sprints. You're saying that, after the 1st month, my Product Manager should be confident in saying "I think we're done. Let's release."??? Not going to happen.

Granted, I'll be able to show progress (value) and working functionality, as I can and do in my project, but you simply cannot "release" after every sprint. It is far too dependent on the type of project you're working on. If the only projects you've worked on have been mature products, then yes, adding a feature and releasing often makes sense. But that's simply not the case when you're starting over at line 1 of code (in an app that's going to require over 1M lines of code before your customer base will even considering adopting it). Our customers have set the bar for what's required to "release." It is very high. It needs to work. As we say, it's about "data and digits." Wrong data or a safety concern and it's an absolute no-go.

I agree entirely about your statement that velocity is simply a tool to forecast, which is what my organization (who provides the funding) requires. They require me to forecast when my product will be able to start driving revenue.

So, back to the original question. Using velocity as a tool to forecast, what have teams done to improve their velocity over time. Surely you've implemented tools, process changes or technology that has allowed your team to get more work done (provide more value) in a shorter amount of time. If not, you are in grave danger of being left behind.

I'm saying that, at the *beginning* of the first month, the PO should be able to say to the team:

"Here is the scope as I currently understand it. What can be delivered in the upcoming Sprint which will empirically test these assumptions about product value?"

Ironically this tends to be easier on greenfield projects more than any other, because there are fewer knock-on effects and the Scrum Team has a clean slate to work from.

This isn't idealized theory, nor for that matter is it a practice that is limited to Scrum. Proof through ongoing delivery is a general agile principle to be observed. For example the Lean Startup movement has demonstrated the practicality of rapid release cycles, especially in "greenfield" development, while so-called "DevOps" teams demonstrate that releases into production can occur at sub-minute levels of frequency, even once scale is attained.

Honestly speaking those estimates and velocity never speaks about the truth anyway, it's a mean to forecast. Any developer can game the number easily. So how can you improve it? And how would your management know it is under control when developers are gaming the number?

So why not remove the notion of velocity and estimate to improve the team productivity?

Joshua's right. Velocity isn't productivity, nor should it be used as a proxy measure for it. The idea of improving velocity will only send you down a rabbit hole. Estimation serves the purpose of sprint planning and delivery.

Hi Scott,

I will go out and say, you are looking at the wrong place to fix your problem with the lack of time. You are having this issue because you do not have scrum. Your organization is not agile. I am sorry, don't take it personally, but that is the fact, what you have is water-scrum-fail. I did not invent it, it was found by Forrester and if you want to read more about it, you will have to fork out $500 (ouch) https://www.forrester.com/WaterScrumFall+Is+The+Reality+Of+Agile+For+Mo…

You, or your PO should turn on the Lean brain, read the Lean Startup, get out of scope thinking and get into value delivery and all of the sudden, you will have more time than you can spend. Until you change that aspect of your or, you will not have time. Your development team is working, by the look of it, as well as they can in a water-scrum-fail organisation, so looking at them to "work faster" is wrong. You should look at the rest of the chain and ask them to work smarter.

I agree with others that you are trying to resolve wrong problem.

I also had a chance to work on greenfield project. This type of project even better illustrates the power of Scrum (if it is understood and implemented at the organization level). In our case, we have tried to achieve the greatest possible value by taking the decision (at given moment). To make these decisions and maximize the value of such a project, we had to validate our assumptions (already mentioned by Ian).

Joshua mentioned about getting rid of the estimation and velocity. I will take that as a "mental shortcut". Estimates are not bad. Very often, the way how we use them is wrong.

And finally the velocity... One thing is to work at the level of organization and show them the value of using Scrum. The second thing is how we work with the team. Increasing velocity can not be a goal. The Scrum Team should work on improving their work at every level (technical, teamwork, cooperation with the environment, etc.). But even the continuous improvement does not guarantee higher velocity. In my teams we treat it only as historical data. Only. Our goal is to improve the work not velocity.

I wish you luck in your work with your organization. It is not easy. In our case, the idea of the velocity does not go beyond the Scrum Team. PO during communication with business is not using this word. And it works well.

I agree with others that you are trying to resolve wrong problem.

I also had a chance to work on greenfield project. This type of project even better illustrates the power of Scrum (if it is understood and implemented at the organization level). In our case, we have tried to achieve the greatest possible value by taking the decision (at given moment). To make these decisions and maximize the value of such a project, we had to validate our assumptions (already mentioned by Ian).

Joshua mentioned about getting rid of the estimation and velocity. I will take that as a "mental shortcut". Estimates are not bad. Very often, the way how we use them is wrong.

And finally the velocity... One thing is to work at the level of organization and show them the value of using Scrum. The second thing is how we work with the team. Increasing velocity can not be a goal. The Scrum Team should work on improving their work at every level (technical, teamwork, cooperation with the environment, etc.). But even the continuous improvement does not guarantee higher velocity. In my teams we treat it only as historical data. Only. Our goal is to improve the work not velocity.

I wish you luck in your work with your organization. It is not easy. In our case, the idea of the velocity does not go beyond the Scrum Team. PO during communication with business is not using this word. And it works well.

In order to increase "velocity", simply throw more money at it and increase the team size by +2. There are a few project variables and only one is fixed, quality. The others such as; features, time, and cost can all change. So my solution would be if they want it to go faster, add more resource, not too much and not too little. Remember to start with the velocity may decrease as the new members are coming up to speed and time is being taken out from your currently development team members to help them get up to speed too. Overall this speed balance out and velocity will pick up.

Interesting question asked, how to improve your team's velocity. Exactly the same question I got asked by my management as well. I think the responses as in this forum are too much focusing on velocity itself. I agree, you should not steer on velocity. You should steer on improvement to achieve a higher outcome.

And that's exactly what management is asking. They are not asking for a higher velocity persé, they are asking for a higher value output. So instead of focusing on velocity we should focus on improvement.

To do that, first you should think about what is influencing the level of your outcome, which might be many factors like prioritization of features or user stories, complexity, competence of your team, changes in scope, amount of Technical Debt, defect rate, defect detection gap, amount of test automation, tooling and so on.

You could consider start measuring:

- technical debt items on backlog

- rework percentage

- defect velocity (the rates at which defects are found and fixed)

- scope velocity (the rate at which scope is added)

- complexity of features or user stories

and actively discuss and manage these metrics in your team to improve.

However since this forum was posted already several years ago i am very interested how Scott handled the question.

Thank you.

The topic of velocity is intriguing indeed :D

Usually, the whole 'Agile' dogma preaches that we should focus only on delivering value to the market as soon as possible. I must agree that this works fairly well when funding is not scarce, and the company can affort building product increments without the money running out.

But it seems to be problematic for startups that are raising capital from investors. When a startup asks for funding, it is usually asked for the ROI and for a guestimate of how far along will their project be. This rimes with waterfall, as in waterfall you have tight budgets for getting a project to a certain state.

The sad thing about this world is that most high level organisations allocate budgets in order to get things done, as no organisation can boast unlimited funding. The same is true for the state as well. If you manage to obtain state level funding, you can bet that they will expect some deliverables by a certain date. The organisations that usually stop caring about budgets, are usually large enough as to actually 'forget' that they're contracting a service from a provider, and so the development team continues to move buttons around at will (until a freshly hired improvement manager find the project as a leek, and cuts its budget for a promotion)

We can't blame the system for working this way, as all optimised industries tend to know the effort for building stuff pretty accurately (think of mass manufacturing where the fail rate of deliverables is around 4-7 parts per million). Comparted to other industries, the software development industry is all fairy tales and hahas, without a clue on how to exactly measure project deadlines.

Delivering software for startups will end up being water-agile as they run on limited funding capabilities. A startup will always want to know how much bang they can get for the buck, before their pond is dry. This is why, as project managers we have to compute velocities, because it's a means of quantifying the amount of value shipped.

If we don't compute velocity and assess burndowns, how can we size a team? Are 5 developers enough for a department or are they one too many? What happens if a senior quits, and as a desperate measure is replaced by a mid level developer. How can you tell if the project is on track without velocity? :D

So velocity is our friend. But can it be increased? I'm struggling with the same question now as we're developing a project for which we had to allocate far more devs than our budget predicted, and as our budget is state issued, we have some pretty damn fixed deadlines. When asking the team to step up, they tend to get into a deffensive way of thinking because their confort zone is being pushed (as would anyone who is not an adept of change).

When the team adopts this mindset, velocity goes down, as they will suddenly feel overworked. So just suggesting the increase in velocity will never cut it, and the team will always fight it.

In conclusion, I think the only way to increase the velocity of a team is by stimulating the appropriate collective mindset. A team that perceives themselves as "the ones that can deliver against all odds" will actually end up being the ones that do.