By Ian Mitchell
rawpixel / Pixabay
“See it all. See it fairly. Be truthful, be sensible and be careful with language” – Henry Grunwald
In Scrum, we care about the precise and considered use of language, since any obfuscation reduces transparency. When we try to implement Scrum, we can sometimes find that the pressure is on to change Scrum terms and their meaning, so that change may be “configured” or “customized” to fit the organization. Scrum terms of reference can become bent and twisted around those existing contours, and the way we even think about agile change can be tugged at and constrained by organizational gravity. The result of acquiescing to such pressure is that little change may actually happen, and there is surprise and disappointment amongst stakeholders when the expected benefits do not materialize.
We are nevertheless subject to those forces of organizational gravity, and no matter how rigorous or careful we try to be, we cannot entirely insulate ourselves from its effects. An important discipline we must therefore learn is to exert small corrections, early and often, before they build up and we face a crash. Here are twenty small things which you might be tempted to say or to silently agree with, and which are perhaps rather better to avoid.
- Avoid describing a Sprint Backlog as a “commitment”. It’s a “plan” or “forecast” of work for meeting a Sprint Goal. Use those words instead. Remember that team members ought to commit to goals, not to forecasts.
- Avoid language which suggests Story Points are “delivered”, or in some way constitute value or otherwise proxy for value. The purpose of story pointing is to help a team forecast how much work it believes it can take on. In agile practice, value is only to be found in the delivered increment itself.
- Avoid talking about an “ideal velocity” when making forecasts. Instead, talk about the ideal value which can be released in current and future Sprints. Remember that an agile team does not consist of story point accountants. Speak of the work done in terms of innovation accounting instead.
- Avoid talking about “Sprint Goals” when those supposed goals have not yet been planned and agreed by the team. If they are tentative Sprint Goals, call them that. During refinement, discuss how well they might align to features and Minimum Viable Products.
- Avoid describing stages of work as “Sprints” unless they are time-boxed and produce an increment of functionality, however small it may be. “Special” sprints like “sprint zero”, “integration sprint”, “testing sprint” and so on are coded terms for stages or phases. If stages or phases are to be used, call them so honestly, and avoid devaluing agile terms of reference.
- Avoid describing a Sprint Review as a “Show and Tell” or “Demo”. A demonstration of work might very well form part of a Sprint Review. However, the essential purpose is to consider the work which has been done and which remains to be done, and to inspect and adapt the Product Backlog.
- Avoid talking about a “Kanban” unless there …read more
Read more here:: B2CMarketingInsider