Writing Verifiable Requirements should be a rule that does not need to be written. Â Everyone reading this has seen or created requirements that can not be verified. Â The primary reason for writing requirements is to communicate to the team what they need to accomplish. Â If you can’t verify that what the team delivered is acceptable, neither can the team. Â This may be the most obvious of the rules of writing requirements – but it is ignored every day.
Monthly Archives: August 2010
Foundation Series: Inside A Scrum Sprint
People who already use Scrum will only find one new thing in this article – a way to communicate what happens inside a sprint that has proven effective for me.  People who are new to Scrum who wonder “how do things work inside a sprint?” will see how things work in a way that avoids hyperbole and is easy to map to what they already understand from traditional software development processes.
Read the rest of the article …
Writing Unambiguous Requirements
Writing unambiguous requirements is about understanding what is written, and what is read. Â Without a clear understanding of your market, you can’t write unambiguously. Â Even when you understand your market, you risk writing something that is ambiguous to your readers. Â Documenting requirements is about communication. Â Don’t break this rule, or you’ve wasted all the energy you spent understanding your requirements.
Latest Articles
Comments on all Articles
