Empiricism and Truthiness

Photo by stricken_family

Ken Schwaber, one of the founders of Scrum, describes Scrum as an empirical process--“the art of the possible.”  It's about making decisions based on what is.  But I've been noticing a trend where Product Owners and Scrum Masters are not diligent in keeping the Product Backlog and user stories well-organized and groomed for effective reporting to stakeholders.  Basically they're not using the company-prescribed tools very well, and I'm starting to see how it's affecting other parts of the organization.  

Managers are looking at burndown and burnup charts to determine if teams are on track with their projects--even though the teams themselves do not rely on the same charts to measure their own progress.  Program managers are trying to understand when a team might be reasonably expected to complete work based on its velocity and story point estimates, but it's impossible to see clearly how much work is remaining to be done.  How do the Product Owners, Scrum Masters, and team members know if they are on track?

Apparently they rely on their gut.

Don't get me  wrong--there's something to be said for gut feelings and good instincts in the Agile world.  But how do you scale gut feelings or radiate them to others effectively?  I'd love for managers and stakeholders to talk to the team to learn what's going on and what's coming next, but unless a team is delivering to production on a very frequent basis [at least once a month, in my opinion], they should be able to look at an information radiator of some kind to understand some of this basic information.  We don't want to make decisions based on truthiness--we want to make decisions based on truth.  The only thing worse than not having information radiators available is having people look at the reports available in the previously mentioned company-prescribed tools to make decisions when the data is wrong.