Some folks criticize agile approaches to software development like Scrum, Kanban and XP, with the claim that there’s too much emphasis on the end user. How can you develop software systems that are robust, fast and secure using stories? End users are not going to write stories defining the technical characteristics of a system.
That last statement is true — they’re not. Would a software developer even want them to define software implementation details? I wouldn’t.
Such nuances aside, the technical or non-functional characteristics of a system are just as important as the features and functions seen by the end user. No one wants to deal with a software system that’s slow, unreliable or insecure.
Covering all aspects of a system’s behavior begins with the 3 C’s — Card, Conversation and Confirmation — so let’s start there.
You’ve heard it many times before — stories need to be short regardless of the role of the user or the nature of the story. They should fit on a 3×5 inch card.
I’d prefer to use the term Collaboration but regardless, business people and technical people need to discuss each story and assess its implications. At times, seemingly simple requests turn out to be complex. For example:
As a financial analyst, I want to download all transactions for last quarter into a spreadsheet so that…
What if the number of transactions exceeds one million? The file may take a long time to generate and it will be too big to load into Excel. The request could be batched so the user doesn’t have to wait for completion. The file could be split up into two or more subfiles though there needs to be an algorithm for deciding where to make the splits. Or, perhaps whatever the analyst wants to do could be done by the software internally eliminating the need for downloads.
It’s up to the software development team to drill down and assess the implications of a story and design a solution set that solves the problem without creating new ones. This is only possible when open conversations take place.
This ‘C’ is about testing the story and satisfying the definition of done. Testing any story should cover boundary conditions, performance characteristics, security concerns, etc. These non-functional issues won’t be explicitly addressed in the story but they are just as important.
When discussing a story with the Product Owner, take the time needed to inform and educate. Be sure that the point value assigned to the story covers all the work required to deliver a complete solution.
But wait, there’s more!
You can probably tell that the approach I’m advocating will result in some stories growing in size. You may need to do some story splitting to make the work units fit inside your sprints. That’s okay. As long as everyone is collaborating, there will be no surprises and the end result will be robust.
It’s also okay to have some system stories. For example, your company may have a data warehouse and you’ll be required to extract, translate and load transactions into the warehouse nightly, weekly or monthly. It’s perfectly fine to have a story (or epic) along the lines of:
As a corporate data store, I want the ability to send transactions to the data warehouse each night so that…
The “user” doesn’t have to be a person. It can be another system.
In summary, think about the technical characteristics of the system when evaluating and implementing every story. Add system stories when needed to cover functionality that users may not be aware of but is mandated for other reasons. The end result will be a software system that meets everyone’s needs.