If after three or four sprints you notice your velocity is not where you had hoped it would be, do not panic. This might happen, this is why you need to set expectations accordingly and told your client not to trust your initial plans. The good news is that by the time you know about it, you can adjust course as necessary.
Being flexible about scope is the preferred method for restoring balance.
The important thing is to have the conversation and give your client some options. Yes, this may make you uncomfortable, but you can’t hide this stuff. Bad news early is the agile way.
There is one strategy for ensuring that when you do have the “too much to do, not enough time” conversation:
If you can’t deliver a minimalist version of the application with the time and resources you have got, then the plan is clearly wrong and needs to change.
It works like this:
- take one or two really important features for your project (something core that goes from end to end through your entire architecture) and
- measure how long it takes to build a minimalistic version of those features
Then use that against your remaining relatively sized stories to see whether a minimalistic version of the application is even possible with the time and resources you have.
If your dates are looking good, right on, if your dates are looking bad, great, at least you know about it now.
When you need to change the plan conversation from, It is not based on wishful thinking. There is no need to get emotional, it is just the facts. It is better to know this now than later.
2 thoughts on “In Agile, What to do if Team Velocity is not as you Planned?”
Great advise. What method of contract (fix price or T&M) do you use in this case?
Hi Joshua, good question.
It all depends on the industry and type of project; but in my case software and digital solutions:
– If the requirements are small, clear and detailed; you can follow a waterfall plan and there is no harm in going fixed price.
– If you think that you will invest too much time on getting a deep understanding of requirements (let’s say your sector is very innovative and agile) and a resulting sequential waterfall plan urges you to have big contingency on the price (20%+) , then agile approach with a Time & Materials (T&M) contract seems a better option.