over and over I’m seeing agile teams that don’t have any clue about their “velocity” be it story point velocity or pure story throughput. Now velocity in itself is not of any special importance to me.
What is important for an agile development team is to know how much it can do and what it can’t especially in the long run.
In order to know if a release date or sprint goal can be met or not there is one prerequisite.
Did you ever have mold in your house or flat? When did you notice that you have a problem?
Most people find out when it becomes “visible”. Sadly some only find out after the doctor tells them.
So before you get into problems create an environment that will highlight where you’re standing compared to where you want to go. You basically want to find out if you have an environment that supports mold.
Transparency aka lo-tech solution
Tools – the holy grail. Some go totally crazy about tools. I have one tool for you, it’s quite universal and you can impress some of the best engineers with it.
Are you using a digital tool as agile board? Maybe something like Jira or one of the many many alternatives. Do you also have a state of the art digital board like the one used in the film Minority Report or in many of the current series in TV to display your board for the daily standup? No?
Then you’re part of the majority of teams.
If you’re a scrum master or PO then there is a good chance that you look at the burndown or progress report that the tool of your choice provides several times during the sprint.
How about the team?
Are you talking about the current progress vs. the sprint commitment and sprint goal?
Recently I saw a Scrum Master doing a thumb voting with her team one day before the sprint ended to find out how certain the team members were that they can meet the sprint goal and finish all the left over scope. That’s one way, but there are other ways that are easy to do and don’t require any tech-voodoo to succeed.
If it’s visible team members will care
Instead of printing out the digital version of your burn-down/burn-up or progress report every day you can just do it manually in your daily standup. That will actually save some trees. This is how it could look like. This example is the 4th or 5th burndown in series after starting to do it manually and continuously working on actually achieving the sprint commitment. So it took the team 5 sprints to inspect and adapt to be able to actually achieve their commitment.
The key here is that the information has to be visible constantly, all the day all the sprint. The story or task board area burndown should be a focal point of communication. A reason for the team to constantly reflect on how they are doing and what they might do to achieve their commitment. It’s not primarily a tool for the management or the PO or controlling. That’s only a side product. It’s from the team for the team.
So if you have seen enough of these digital reports it might be time to try something new?
Go grab some of the easy to use tools introduced above and start knowing your progress immediately. Do it together with the whole team. Only then will they begin to actually show interest.