How to distill a Client-provided SRS into well formed Stories, fitted to be consumed in Sprints?

Last post 10:53 am April 3, 2021
by Thomas Owens
6 replies
Author
Messages
07:58 am April 2, 2021

Dear all,

Greetings of the day!

We've just got a new software product-work from one of the Client departments which has never worked in Agile. They have provided us with several SRS documents which need to be worked upon as part of the different functionalities of the target software product.

This Client is fairly new to Agile and want us to adopt Scrum to develop & deliver their product. The problem is that they have already come up with detailed SRS documents (with several section, sub sections, sub-sub sections and so on...) and have asked us (the solution provider) to adopt these as requirements to start with our development activity. The Client Business Analysts (not POs) will be available to answer any queries related to the document contents but they're not going to help distill these into User Stories, to be worked upon in Sprints.

As a Product Owner of my Scrum team, I'm really struggling to find ways to distill these requirements (every section seems to have dependencies on another sub-section) into User Stories, to be fitted into a new progressively elaborated Product Backlog. Any suggestions on how should I proceed in this scenario will be very helpful!

Thanks in advance!

10:03 am April 2, 2021

Why do you want to convert these requirements into user stories? To me, that seems like wasted effort. You have an expression of need from the stakeholders. Rather than turning them into user stories, I'd just try to get them out of a document form and into a better format for requirements management that will allow you to capture dependencies and start to order the work. Once you have an ordered backlog with enough work in it, you can start development when continuing to put the rest of the requirements in the backlog.

Since you're using Scrum, you'll have a Sprint Review at least once a month. At the review, use this to synchronize with the client's Business Analysts and show them what requirements have been completed this Sprint and what the top of the backlog looks like. If it's like the majority of software efforts, they are going to have opinions on what the next work should look like. Perhaps that means they'll come up with something that is not in the original requirements document. Perhaps they'll decide that something in the requirements document isn't truly needed and can be dropped. Agile methods like Scrum give them this advantage.

01:08 pm April 2, 2021

This Client is fairly new to Agile and want us to adopt Scrum to develop & deliver their product. The problem is that they have already come up with detailed SRS documents

That being the case, why do they want you to adopt Scrum to develop & deliver their product?

Have they expressed a desire for those requirements to be revised each Sprint, based on lessons learned?

06:37 am April 3, 2021

Thanks @Thomas Owens for your suggestions!

I agree that Scrum doesn't dictate defining requirements in User Story format. However, that being said, we would need to find a way to break down the requirements sections and sub-sections in the SRS into small, estimable and well-sized chunks that can be worked upon within a Sprint and be delivered. We can call it User Stories or whatever else we wish to call.

On that note, I didn't quite understand your point of - 'Rather than turning them into user stories, I'd just try to get them out of a document form and into a better format for requirements management that will allow you to capture dependencies and start to order the work'. Isn't this similar to a Use Case/ User Story or a User Voice? Breaking them into manageable chunks would also, on the other hand, enable us to create a Backlog which we can then have prioritization discussions with the Client BAs during Refinements and Review sessions. 

I'm completely in-line with the your second paragraph of having those discussions and collaborating with the Client BAs to gain valuable feedback and knowledge of the shape of things to come next.

Regards.

06:43 am April 3, 2021

Thanks @Ian Mitchell for your response!

The primary reason Client wants us to adopt Agile & Scrum is that they want to see working software at quick and regular intervals, so that they can make informed decisions upon the next set of priorities to work upon. They have provided us with an MVP/ MMF to work upon first wherein they'll evaluate their hypothesis on the basis of the minimal working solution and then decide on the 'pivot or persevere' decision.

Regards.

07:47 am April 3, 2021

A detailed SRS doesn't sound like an MVP learning experiment; rather, it would indicate that a significant leap-of-faith is being taken before empirical results will be obtained.

My advice would be to start with a release-quality Definition of Done. Once that is understood and in place, a minimum viable product can perhaps be elicited -- the smallest thing which can be Done at all.

10:53 am April 3, 2021

On that note, I didn't quite understand your point of - 'Rather than turning them into user stories, I'd just try to get them out of a document form and into a better format for requirements management that will allow you to capture dependencies and start to order the work'. Isn't this similar to a Use Case/ User Story or a User Voice? Breaking them into manageable chunks would also, on the other hand, enable us to create a Backlog which we can then have prioritization discussions with the Client BAs during Refinements and Review sessions. 

Possibly. Without seeing the SRS, it's hard to say for sure. I was mainly referring to getting them out of a document and into something else. If I had this problem, I'd probably turn to Jira because I know it has what I need. I could probably get what I needed out of a spreadsheet, too. There are also other requirements management tools that offer linking dependent requirements, decomposition, traceability, and other features like that.

In Jira, I'd use custom fields to reference parts of the SRS, issue linking to start to identify dependencies, and labels, components, and hierarchies (defaulting to Epic and Story, but can be modified) to decompose into related bodies of work rather than just the hierarchical tree of an SRS document. Then, work with the team to start to think through them all. The format you use to capture the decomposition of items isn't really relevant, as long as you get them to levels that are small enough to complete in a reasonable timeframe - at least within a Sprint, if not a couple of days. The linkage and references to SRS identification numbers can help when you complete work, you can relate what was done back directly to the relevant parts of the SRS.