Talking to a team about carryover at a daily scrum meeting led me into a very uncomfortable confrontation with someone who already didn’t like me. Not sure why but I ascertained it had something to do with the unhealthy relationship between product and technology organizations and the fact that product was pushed by sales to make commitments on behalf of the teams that were essentially never met on time (more on that issue in a later post). So a contentious confrontation – read on…
Let’s talk about cost of delay – the cost of having NOT done something. Basically the opportunity cost of choosing to do one thing over another. Seems simple enough but it’s not.
This is a good follow on to the velocity and capacity discussion. If velocity is the amount of new feature work we can get done in a sprint and capacity is the amount of bandwidth we have in the sprint, other stuff fills in the delta between velocity and capacity. SO…do we estimate it?
We have a problem. Ok, I have a problem. I’m realizing velocity is often being used as a synonym for team capacity. In fact, I’ve done it, too. Don’t think that’s a problem? Well it impacts our forecasting, estimation, team health, and organizational expectations.
A rant about estimates, #noEstimates, relative estimating, story points, ideal days. You might learn something or more likely will just be mildly entertained. What else did you expect for a return from a 6+ month hiatus? Oh and also a sneak peak into my research project and how YOU can get involved — check back in March.