September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
Similarly, Velocity works find as a means of providing history and forecasting, but it works best when based on the entire backlog, not detailed sprint planning. Using velocity as a performance metric will often prove counterproductive. This is especially true if you're using story points. The team will merely start gaming the system to show an artificial increase in their performance. This is human nature; they may not even realize they're doing it.
You're asking a very good question about team health, I just don't think the answer is an easy one. There are a number of factors you can consider, but few of them are easily measured. You could even argue that the most important elements of team health are human factors that cannot be quantified. In the end, you have to figure out what a healthy team looks like, and find a way to compare this ideal image to your team- like Norman Rockwell checking his reflection while painting his self portrait of himself painting his self portrait.
You might be dealing with a upper level manager who wants some sort of KPI on team health; some number this person can use because business schools teach that we can't manage what we can't measure. (Deming says this is a myth.) I can only wish you the best of luck. The lack of support or understanding from organizational leadership is often cited as the leading reason why Agile transformations fail.
Story Points are a very bad metric because they can be gamed too easy. The level of precision is also too wide.
From the Agile point of view "velocity" means nothing. The purpose is to adapt to change not to deliver fast. Fast delivery means eliminating waste (Lean SIx Sigma) and it's another established discipline.
If you really want to find out how effective is your team and your process then Six Sigma is the best way. In terms of measurement Function Point is a much better approach. 1 because is consistent and 2 because you can compare multiple approaches by using Data repositories.
Team can easily increase velocity by allocating 8 points instead of 5, that's a 60% increase in velocity or splitting a 3 story in 2 stories that have also 3 points allocated, doubling the "velocity"
It defies the purpose of measurement.
The other good point is the lack of support/involvement at the executive level. That's the main cause of project failure regardless the framework and I've seen many organisations 'adopting' Agile as a solution to this. Agile doesn't solve lack of money, time and commitment. It manages scope a bit different but that's all.
A healthy team is a team that delivers what they committed to: "Working software is the primary measure of progress." Any other metric can be a sign that the organisation is not Agile.
Hey Andrew, I would recommend following book: -
This should answer question on what should we measure. At high level it talks about: -
1. Lead time - Time it takes to develop from idea to tangible piece of code. Sub metrics could be velocity etc etc.
2. Deployment frequency - How frequently can the team deploy in production. Code which does not end up in production when you need it, is no good.
3. Failure Rate - How frequently are we failing in production - too conservative is not good either. Fail fast -- Learn Fast -- Improve fast
4. Time to restore - If we fail, how quickly can we recover.
Please login or join to reply