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.
Card
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.
Conversation
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.
Confirmation
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.
May I express my disagreement with the following reason – though the users wont think of technical details that are essential to making a good product, and hence cannot be expected to come up with such requirements, the very fact that those technical details are required for a “good product” shows that even such a need must be defined with the user in mind. For a user is the ultimate authority on what a good product means. And as a systems engineers I would think it my responsibility to be able to translate those features that users would come to regard as a good product into appropriate details in the conversation.
As to the question of how then would good design and NFRs get incorporated – would not this story cover in its Confirmation the scenario you have rightly said to be a technical need that the user may not think of:
As a MIS User I want the transactional data to be available the next day for summarization, so that I can make sense of the previous days performance.. etc. etc,
To achieve the above, one would have to have the data stored. Or may be not. Maybe all the user needs is a FTPed dump or an excel mailed. And would that not be the very reason it is important to not write system-centric tech stories, but keep the end user in mind, always?
You make a good point, Ram. It’s possible to capture user information in a variety of ways. Thanks for your feedback.