Scrum and non-functional requirements
The qualities you must not ignore 2021-09-21 #agile
Project teams using Scrum tend to focus on implementing the next set of features. Features don’t describe everything that matters, though. You also need to work on fixing bugs and usability issues, and improve performance and scalability.
Reliability, security, usability, performance, scalability…
You can get into trouble if you neglect bugs and security requirements. An application can become so buggy that the development team gives up on ever fixing all known bugs, while users give up on the idea of the software ever becoming trustworthy or reliable.
Similarly, people experience good (and bad) usability in every system interface (not just the user-interface). Usability does not come from a set of features that you can just add to an existing system later on.
Performance and scalability requirements differ somewhat. Although you can measure a system’s overall performance, good performance relies on repeatedly tuning specific performance bottlenecks. Trying to make everything ‘fast’ first time leads to premature optimisation. Scalability requirements, meanwhile, tend to depend on business requirements that evolve over time, such as an on-line service’s number of users, and have high costs that are best delayed.
Functional vs non-functional requirements
Software development involves two kinds of requirements. Functional requirements describe features, such as being able to send e-mail. Non-functional requirements include qualities, such as reliability, usability, performance and security. Wikipedia has a long list of non-functional requirements, which all contribute to overall software quality.
Scrum projects risk neglecting non-functional requirements, resulting in poor-quality software. Product owners may find it natural to think about progress in terms of user stories and features, while holding the development team responsible for the ‘quality’ of the resulting software. This creates a tension with developers who don’t feel that they are free to work on non-functional requirements.
Prioritising Scrum project requirements
Scrum helps you prioritise, specify and implement functional requirements, typically via user stories, but doesn’t always help with non-functional requirements. The agile manifesto builds on the principle that ‘working software is the primary measure of progress’, but assumes that your team has enough experience and common sense to decide what working means.
The usual solution bakes non-functional requirements into a Scrum project’s definition of done, and any associated review process. This incorporates non-functional requirements for things like reliability and usability into every user story.
Adding conditions to the definition of done increases the time required to implement each user story, as well as the time required to review or test whether you can consider it done. Remember: non-functional requirements require development effort.
Alternatively, each sprint can budget a fixed amount of non-story time that team members spend on technical tasks, such as bug fixing (in the absence of a zero-bug policy) and performance improvements. This comes to the same thing; you choose whether user stories include all work.
Playing catch-up
User-stories that ‘catch up’ on software quality can address some non-functional requirements. Incremental development can can use user stories for specific performance improvements, for example. In fact, many applications would benefit from one performance improvement each sprint, and ‘performance improvements and bug fixes’ in every release.
