We have all worked in environments where either Product managers or delivery heads in a company give high-level vague requirements. But for some unknown reason expect engineering / Development / Implementation teams to deliver tangible results.
In-fact this is a subject I am talking to a fair few people about in the Agile communities I frequent, most notably the Scrum based ones.
During discussion someone asked what is a good definition or measure that can be used to day if a requirement was suitably defined. After some thought I come up with the following definition, but as usual I have some pre-conditions that help out, so here it goes:
"A Requirement specification is good if it allows a person of average skills to implement the requirement without experimentation."
This means that if the requirement is not clear and needs to be explained more, or if the skills of the team implementing the requirement are not sufficient for the task. There is a great likely hood that any understanding of the requirement may well be incorrect.
The best requirement specification should enable a team with the right skills to implement it. However, getting to this level of maturity in product requirements/feature lists/backlogs can be hard. Also it needs teams to be realistic about what skills they do and do not have, and be able to articulate that will need time to research/be trained/mentored in skills required. Or even articulate that the requirement is just not good enough to work on due to its vagueness.
User stories help a little in this, but for a feature from a product/business focus a definition/specification needs to be created that is not vague and can be used as a basis for story creation.
No comments:
Post a Comment