Dealing with quality requirements in Agile / Scrum

You have probably heard of non-functional requirements. One of the most used phrases by architects. Rather ridiculous if you consider it means ‘broken’ in English. The term is already being transformed into “quality requirements” by many.

Example of a quality requirement: response time of a specific request in our system. Or more ambiguous: suitability or maturity. The last two are part of ISO/IEC 9126 standard full of other nice sounding academic words. ISO/IEC 9126 with all the ilities was for me never really useful in practice because it replaces common sense, which proved to be much better without the standard. The common sense of defining our ilities should always be driven by explicitly stated requirements from users and stakeholders.

Question: “In how much time does user wants to complete his registration?”
Answer: “About one minute… In that case, number of clicks should be very low and response times very fast.”

My point is: I don’t need some standard to figure this out. What I do always need is a way to identify them based on real needs from users and business, sometimes quantify them, but mainly a way to measure them. The answer came partially from Planguage created by Tom Gilb. Although I must admit I use it in a rather simplified manner. A quality requirement which I wish to precisely identify and follow is placed in the following table:

Tag
A unique identifier of the quality requirement
Description        
Identifier a bit more explained
Scale
The scale of measure used to quantify the statement
Meter
The process or device used to establish location on a Scale
Must
The minimum level required to avoid failure
Plan
Realistic level considering we have limited budget and time
Wish
User and business would say “Wauw!” if we achieved this level
Current
Currently measured level after each sprint

Nice thing about Scrum is that when you deliver software after each sprint, users and business can tell you how satisfied they are and if quality in identified areas has improved. Even better is the fact that for most of the quality requirements you don’t need to define them before sprint starts, but simply make a best guess, measure qualities afterwards and improve them in the next sprints.

For me the most important part of quality requirements management is the “current” value part. Is it high or low enough? No? Let’s improve it!

Question: “How easy to use should this page be?”
Answer: “We have no idea, because we don’t know how often user will use it and it is too much hassle to find that out. User sometimes think she will use it often, but eventually she doesn’t. It is costly to make it very user friendly. Let’s choose the basic / cheaper version and hear from first users what they think about it. If they are not happy, we’ll adjust it accordingly in the following sprint”.

Another nice thing about Scrum is disappeared need for heavy requirements management because of so many feedback loops. For most of them, we simply don’t need to think about quality requirements much. As soon as you deliver software after each sprint, requirement (e.g. system stability) is going to hit you back (e.g. system down time) and team must improve it. On other hand, this should not prevent a team from making sure that obvious requirements are in place before end of a sprint as part of Definition of Done. E.g. “after this sprint we’ll have aprox. 1000 users and 100.000 requests per day. Can our system handle this load?

4 thoughts on “Dealing with quality requirements in Agile / Scrum

  1. I really like your approach on measuring quality requirements. Your table is a nice starting point to try and apply this myself.

  2. I fully agree with the approach, Victor. I have no clue who coined the term non-functionals. To me these ill formed names can have negative impact on projects and process. There must be a reason why quality requirements are often ignored until late in a project. From a linguistic perspective these so-called non-functionals can be recognized as nouns where in reality they are verbs; verbs meaning 'hidden' processes if you will. Applying meters and scales is good a way to 'denominalize' these hidden processes and to reactive them. Once active we are able to build and test them.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s