I tried to take notes of our conversation on a single index card which got a bit messy! I've linked a scan of this card below but hopefully I've captured the main points of our conversation in this post.
wikipedia. But we also agreed that "non-functional" is a pretty bad name. Roman has a friend who works for Audi and he has responsibility for a system property: weight. Perhaps scrum teams might be better off asking their product owner about what important system properties they need to think about.
We got started by talking about the types of developments that require attention to non-functional requirements. One example, we talked about was Google Chrome where performance was distinguishing feature for marketing and Google did explicit competitor analysis. Another example was a stock broker, for whom seconds cost money, although functionality also has to be correct.
So what's tricky about non-functional requirements and user stories? The first challenge is that a Product Owner might not know that they need to talk to technical stakeholders to get their perspective on the product backlog. This leads to a product backlog which is solely comprised of functional user stories which makes it easy for the team to miss important non-functional aspects. Where a team releases early and often then they can get user feedback which can help reveal this. But if they only have a low number of friendly users then these early releases probably won't be stretching the system and it will only be once the system is under full-load that limitations are revealed.
You can flush out important non-functional aspects of the product at a vision workshop before the team starts sprinting. You can even frame this as a risk brainstorm and make sure key technical experts, such as software architects take part. Afterward, the whole team is aware of what non-functional qualities they need to aspire to. Of course, not every requirement will be anticipated so the team should still expect some aspects to emerge during development.Another approach is to make sure that the product owner has on-going support from such specialists, you may even decide to pair a business product owner with a "technical product owner". Sean suggested that a BA might be a good "caretaker" for this responsibility.
Once you've flushed out some non-functional requirements, the next challenge is making sure that they get planned in. Non-functional requirements are often associated with more than one single product backlog item- like business rules. Attention may need to be paid to make sure they're checked every sprint. Roman suggested that you can make it explicit which constraints apply to each product backlog by building them in as extra columns in the Product Backlog and checking those which apply to specific item rows.
One obvious way to check that software doesn't slip through without non-functional qualities being checked, is for the team to build these checks into their Definition of Done. If it's hard to measure programatically then this turns into a review by someone.
A Scrum team can also establish a Done checklist which applies to the whole Product Increment. Although they will need to allow time at the end of the sprint to execute this and fix any problems. I've encountered instances where some types of testing is expensive or time-consuming and the team has chosen to defer this specialized testing to a subsequent sprint. Although introducing special polishing/consolidation/release sprints is risky because issues may be revealed that require significant rework.As we wrapped up our conversation, Roman also suggested taking a look at what Tom Gilb says in his 1988 book "Principles of Software Engineering Management". Tom emphasizes the importance of establishing key metrics from the outset.
I'm interested in your comments on the above as I'll be giving a talk on this topic at DevOpsDays '09 on October 30-31.