You are currently browsing the tag archive for the ‘ambiguity’ tag.

walmartWhen kick-starting a new team, it’s helpful to be empathetic to each team member’s background and experience.   Interpretation of such concepts as productivity, efficiency, and quality can differ based on an individual’s background, values, and previous experiences.   Ambiguous goals can lead to ambiguous results.

A role of the Scrum Master is to facilitate the team toward common goals.  At face value, this sounds like a “motherhood and apple pie” statement.   Under the covers, this can be more challenging than it appears.    When goals are stated in subjective’ish language, each team member’s interpretation is likely to be different.   

Tip: Know the Target of a Goal.

There’s a difference between goals for the project and goals for the thing being built.  

Project goals tend to pertain to the schedule, resources, and work.     Project goals usually contain language related to efficiency, productivity, being on time, providing good customer service, meeting budgets, etc.

Product goals pertain to attributes of the system being developed.   Non-functional requirements fall into this category: The system shall fast, efficient, comprehensive, fault tolerant, user friendly, etc.

Tip: Make Adjectives Measurable.

Adjectives are inherently subjective.   Product goals such as “User Friendly” and “Fast” have a zillion interpretations.   Rather than “System shall be fast”, try a more specific goal such as “Each screen must display within 3 seconds of request”.

Similarly, a project goal such as “Work Productively” says nothing.   This is where Scrum tactics can help.  Establishing a specific goal for the team’s velocity is measurable, reportable, and actionable.   Once the team agrees to a goal for its Velocity, it can be tracked and reported as a shared measurable goal.

 Tip: Radiate the Goals that Matter.

When goals are written in a document and filed away, they can be forgotten.   If a goal is really important, consider radiating it – perhaps post it on a wall in the team room.   If a goal is not worthy of being posted, perhaps it’s not really that important.


When requirements analysts are thorough, those who read and use the requirements can easily get lost in the muck and mire of the details. I have found that diagrams can add much more specificity to requirements than lengthy narratives describing business rules. This diagram depicts a small excerpt from a requirements model of a financial system.

This tiny drawing eliminates the need to write out all of the following business rules, because they are all clearly shown in the model:

  • Every account must be associated to one customer.
  • An account cannot be associated to more than one customer.
  • An account cannot exist if it does not have a corresponding customer.
  • A customer must have at least one account.
  • A customer may have more than one account.
  • An account must be either an individual account or a corporate account.

Some restrict the use of drawings like this for design, others argue that domain models are old school. I have had great success using this approach for describing business rules. The economy of words eliminates ambiguity, is much more thorough, and can be easier for a designer/developer to use when designing a solution.