Oh dear - talking to yourself! - NURSE - THE SCREENS!!! ;^)
--- In email@example.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
> > But again, specify the requirement, not the implementation, in terms the
> >business stakeholders will understand.
> Mr. Bradley, I would like to clarify something you said.
> By business stakeholders, did you mean the product team that acts as the PO?
> Mr. Bradley, no I did not. I meant the business stakeholders for the component
> team, which almost always includes some business stakeholders from the product
> team, and might include others. Since the PO is prioritizing on business value
> in collaboration with other business stakeholders, it's very important that
> other business stakeholders understand the business value of the story. As
> such, strongly avoid mentioning solutions (the how) or technical jargon.
> Instead, use the business stakeholder's language. This is just as true in User
> Stories as it was in the early days of Use Cases and prose-like requirements.
> One of the major downsides of using technical jargon in such requirements is
> that when one refactors (and remember, we're constantly smartly refactoring as
> our friend Ron Jeffries likes to say) OR changes the technology/solution, one
> has to re-negotiate(or inform of the new) acceptance tests with the business
> stakeholders. If one removes all technical jargon, then one doesn't have to
> re-negotiate or inform, whether it be a refactored solution or a changed
> The other main downside is that if you lose good communication with your
> business stakeholders, they tend to not trust you and eventually decide not to
> pay your salary. :-(
> Charles Bradley, CSM, PSM I
> Experienced Scrum Coach
> My blog: http://scrumcrazy.wordpress.com/