The Role of Technical Stories in a Scrum System Development Project
I was curious how other scrum POs/Project Managers incorporate technical stories into their agile IT projects. Obviously we know user stories are from the business/user perspective, but what about when a system capability/requirement is needed to implement a user story. For the most part, I inform the developers to create Sub-Tasks in the user story stored in JIRA to document the technical work, typically as part of doing Sprint Planning. However I also include as part of the team working agreement, I've established the following:
•Developers may sparingly write technical stories if they feel the need in order to express major system functional requirements needed to implement business user stories, for example:
Example Format: As <System X>, I need to <DO SOMETHING> in order to <system result that is required to support the business user story>.
I was curious about others opinions and such on the use of technical stories to represent major system functional requirements that support the user story and how you handle that.
Obviously we know user stories are from the business/user perspective
Actually I don't know that. I know that a user story is usually written from a persona's perspective. But I have never heard that the persona has to be a business/user perspective. I have written a large number of user stories where the persona was technical. I've even written them similar to "As an application that utilizes our inventory API, I want to be able to get notified if I have ever ordered this product before so that I can determine how long we were able to keep that stock in inventory and determine the proper amount to order this time".
User stories were original created in eXtreme Programming (XP). Over the years the format of them has evolved into what is used today. They were created as a way to have a standard language to communicate requirements. But I know of no agile methodology, framework, practice that requires their use. I will also point out that no where in the Scrum Guide does it mention User Stories. There are only mentions of backlog items with nothing to indicate how they are written. Sometimes even a user request can be captured and communicated better if you do not follow the As...I...so that... format.
In the Scrum framework, the items in the Product Backlog identifies all of the work needed to improve a product. There is usually some type of work needed that is not seen or used by the end user, but has significant impact on improving the product.
I do not advocate that a specific format be used in order to capture the work needed to improve the product. All I advocate is that within the method used to capture the need, it is clear to all what the need is and what it will deliver that improves the product.
For the most part, I inform the developers to
Have you ever asked the developers what works best for them? After all, they are the ones that will be doing the work and need to make that work transparent to anyone that views the Product or Sprint Backlogs. Why shouldn't they be allowed to have input into how to capture and convey the information?
"Developers may sparingly write technical stories if they feel the need in order to express major system functional requirements needed to implement business user stories"
Why is this negotiable scope to be allowed only sparingly? If it's something the Developers must do for work to be usable, they ought to assure it in the Definition of Done.