So here is the Part II, a continuation to Part I, where I raised the couple of must haves that have been expressed in Scrum as measured by the iterative Nokia standards – ref: Scrum and XP from the Trenches, by Henrik Kniberg. Just as a reminder the two must haves were stated as:
- The Product Owner must have a Product Backlog with estimates created by the team
- The team must have a Burndown chart and know their velocity
The first of these was dealt with in Part I, so:
- What of the team must have a Burndown chart and know their velocity?
Burndown charts are unique to a team, given the mix of talent and experience, and in reality they are not forward looking – which is to say allowing one to project what is expected in the next sprint based on current burndown chart. They really are a record of past performance and really a barometer in highlighting the anomalies that may have occurred during the sprint that blocked the team achieving what they had planned. During the sprint it is used to signal to the team to make decisions of reallocating resources within the team, doubling down on the most difficult area as well as having the reality check in terms of scope that was targeted for the sprint. This is after all agile in practice, making good sound decisions to support what needs to be done in order to get the team back on its course to meet its commitments. Really I’d like to say such occasions are rare, but the truth is far from this. Lets remind ourselves that the endeavor of software and system development, and really the realm that knowledge and creative workers play in is not a production line, often there are managers who loose sight of this. So at times like this, when decisions are being made, it is helpful for the team to think lean. Ideally one wants the team to think lean through out all iterations, but in particular get into the practice of putting their hat of lean thinking when ever weighing up decisions to address how can the team best to reach the goals that they have committed to. As I said sometimes this may mean doubling down with resources from within the team on a particular task at other times the hard reality may be that the team has overloaded the plate and can’t possibly consume all that in time boxed for the current iteration. The hard reality of decision making may mean delaying the release, this may be especially true if the rhythm of release in your environment is of high frequency, say every week or two weeks versus every three or four months.
So what about knowing your velocity. Let me start by some basic physics, velocity is a vector, it has a direction and magnitude. The magnitude is measured as speed – you know in m/s. Fundamentally given my Engineering and Physics background I have a problem with the loose use of this term to connote what a team is capable of accomplishing as number of story points delivered per iteration or in the macro view story points delivered per release. Aside this objection, one wants to be smart about using this metric in predicting and really looking forward as to what the team is capable of accomplishing. I say smart, as far to often variables that have a strong bearing on this metric may have changed. For instance my experience has been that the team complement changes after one of two releases, or for that matter the release cycle changes, and or most critically one hasn’t sized the backlog to the same standard. After all this is not the repeat cycle of building the same widget over and over. For the greater part there is variability in developing something different but for only using similar patterns that one may have encountered when developing earlier items of the backlog. Even when this is the case there may be new set of complexities that were just not present previously. Far too often stakeholders do a linear intra/extrapolation and then confront the team with the 64,000 dollar question – why not as much as previous releases? Some see it as holding the teams feet to the fire, thats one way to make stew!
My good sense says be pragmatic with use of this metric; first monitor it over a reasonable period of time. Then use statistical methods of measuring standard deviation about the mean that the team should try to achieve. One can set the lower and upper limits that are 6 sigma from the mean in this metric as the boundary points for the pessimistic and optimistic with the mean value representing the most likely in size for delivery during a release. Over time, with the team maturing as a work unit the tolerance may be narrowed down to 3 sigma thus giving higher fidelity in the estimates of what the deliverables are going to look like. In essence work with the team to establish this metric pointing out the use it is going to be put to as there are supporting cast besides the Product Owner, such as Sales, Marketing and Capacity planning, who are in the business of drumming up more customers for the product as well as setting expectations to existing customers.
Fundamentally, are these truly must haves, sure for high performing teams, but such teams are not build in a day or by virtue of few days spent in training on Scrum or one other Agile practices. Truth be told more often then not it is both the organizational and/or team culture that one has to foster in order to achieve teams to become high performing teams in nature. Let me know which team doesn’t want to become high performing and is this even a willful act on the part of the team? – Possibly in an environment that has fostered the wrong culture, but for most part these must haves are a work in progress. By the way these must haves are not the only metrics of measure to assert a team with the title of high performing in nature. I will save this topic for another day.