how-should-technical-stories-be-handled-scrum

Trainer Talk Podcast: How Should Technical Stories Be Handled In Scrum?

how-should-technical-stories-be-handled-scrum
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In this episode of Trainer Talk – the supplemental series to the Agile Coaches’ Corner podcast – Professional Scrum Trainer, Eric Landes, addresses the question: “How should technical stories be handled in Scrum?”

Listen on Google Play Music

 

Overview

I have often been asked how technical stories should be used in Scrum. This is a great question. Of course Scrum has a framework, while not specifically focusing on this issue.

When discussing technical stories, I typically think about things like product performance, system availability and security. I refer to these as nonfunctional requirements (NFRs), and the Scrum Guide does not specifically speak to these. However, the Scrum Guide has this to say about the Product Backlog: “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.”

So, looking at the Scrum Guide definition, it would seem that we can put NFRs in the Product Backlog. Of course, the last sentence of this section of the Scrum Guide: “The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering,” means that the team needs to work with the Product Owner on the NRFs that belong in the Product Backlog.

 

Example of a Nonfunctional Requirement

Here is an example of an NFR that might be used in the backlog: The team has a screen on an application that shows personal information, including credit scores to a sales administration user of your application. Your security team has deemed that personal information like this cannot be displayed due to certain laws within different countries. Your Product Owner could add a PBI that hides data on the sales administration screen. This doesn’t add functionality, but it does takes care of a nonfunctional requirement.

 

Refine Definition of Done

I also tell students that NFRs that apply to multiple PBIs might be a candidate for “definition of done.” For instance, if we have a security requirement that all code must first be run through a static code analysis before being dealt with, then we might put running a static code analyzer against source code as part of our definition of done.

 

Update the Acceptance Criteria

Another way to deal with an NFR is to place it in the acceptance criteria of a PBI. Let’s say we have a feature that includes posting data to an external data store. The requirement was that after a sales transaction, the sales data needs to be pushed in that data store within 10 minutes of the transaction. We could easily put that into an acceptance criteria.

 

Conclusion

The bottom line is that while technical stories, or nonfunctional requirements, are not mentioned explicitly in the Scrum Guide, the framework gives teams ways to handle them. And, in typical self-organizing fashion, it is up to the team to determine the best way to handle this for their application.

 

Provide Feedback

Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at podcast@agilethought.com.

 

Want to Learn More?

Stay Up-To-Date