I am currently coaching a non-development team on Scrum practices. The team is focused on back-office, administrative processes. This makes the work somewhat of a pull-queue where Kanban would be a better fit if the actual completion of work-product were not externalities to the team; as it is, Scrum was chosen a the framework due to its focus on stand-ups and retrospectives, which the organization believes will improve intra-team communication and lead to incremental process improvement.
"Fail Early" and "Improve Intra-Team Communications" as Sprint Goals
Recently, the team identified "fail early" as the Sprint Goal for an iteration. The idea was that tasks that can't be completed on time may not have alternative solutions or work-arounds---the business model accepts the risk that some percentage of tasks will fail, regardless of process efficiencies---but that these impending failures needs to transparent and visible to the entire team.
The goal of making early failures visible ties directly into the corollary objective of improving intra-team communication. This goes somewhat beyond the task coordination and blocker-identification of a daily stand-up; it requires a bit of a paradigm shift in the way that the team communicates with one another on a routine basis.
To the extent that the goal and its corollary was chosen by the team as a Sprint Goal without a concrete metric to determine if the Sprint Goal was done or not-done, I take responsibility as the Scrum Master for allowing that to happen. I still believe that these were valid objectives for the iteration, but they lack concreteness and a "definition of done." In retrospect, neither of these things has a self-evident performance indicator that can be tracked with any precision.
How to Measure Semi-Subjective Process-Improvement Goals
"Fail early" is somewhat subjective, but I believe I could potentially measure that by calculating the elapsed time from work-item start to its announced failure, and then tracking the "failure lead time" (e.g. the time between when a task is declared "failed" and its original due date). Perhaps there is an even better metric that I haven't considered yet; I'm certainly open to suggestions in that regard.
"Improve intra-team communications" is squishier. Effective communication is a soft-skill. Anything I can think of measuring (e.g. email volume, status fields updated in the job queue, etc.) are at best proxy metrics, and not particularly accurate ones at that. So, other than polling people for how well they feel communication is going, I can't think of a practical way to measure this necessary (but perhaps poorly-framed) objective.
Given the stated Sprint Goals, and assuming a priori that the organization sees value in achieving those two goals:
- How can I measure them in a concrete, meaningful way?
- How might I adapt these (or similar) soft-skill goals in the future to better identify valid, trackable metrics?