Can a Traditional Functional Specifications Document be converted to User Stories?

Agile Projects, especially those using Scrum use a Product Backlog which is a prioritized list of product features or functionality. User stories have emerged as the most popular form of product backlog items. If you are someone new to Scrum or if your organization wants to adopt Scrum as the approach for a new project then one of the questions you may have is, can I convert a Traditional Requirement Specs or Functional Specs document into user stories?

This is the question, this article is trying to answer.

I will be using the term FSD throughout this article which is just the short form of Functional Specifications Document (also called as Requirement Specifications or Requirements Document in different organizations)

Can a Traditional Functional Specs Document be Converted to User Stories?

Exactly as a 1:1 Replacement – No, not possible. For a change, I have started out with the answer so let’s understand the Why part.

Reason 1: Different Purpose

An FSD covers the entire set of features the software system is supposed to have and is a binding agreement between the party that commissioned the work (usually a client) and the party that is building the product (a services company). An Agile product backlog is an evolving wish list of features for a product and does not refer to a binding commitment or agreement. When we reach the end of the release there may be some items in the backlog which are yet to be implemented in the product whereas we don’t have that liberty in an FSD. If it is present in the FSD, it has to be implemented – PERIOD.

Reason 2: Size

An FSD does not bother about the size of the feature requirement or schedule or whether the feature can be completed in one Iteration whereas one of the key considerations for a user story is whether it can be finished in One Iteration. If a story cannot be finished in one iteration Scrum recommends that we work with the team & product owner to break it down into smaller pieces. This may not be entirely feasible when we are trying to convert one section of the FSD because the FSD wasn’t built to take these things into consideration (Ref. Point 1 – Purpose)

Reason 3: Dependencies

It may not be practically feasible to implement feature 1.1 of the FSD without also implementing 1.3 and 1.5 (or maybe more) simultaneously. Whereas, every user story is supposed to be a granular piece that can be implemented individually. When we try to schedule user stories we may need to commence on multiple stories in parallel which could result in one or more of them being incomplete at the end of the Iteration. In ideal scrum world the team wouldn’t start off on so many stories if they know they cannot finish but while working on a converted FSD the team may not have that choice.

Reason 4: Priority

There is no specific order in which the contents of the FSD get translated into the software product. The team could go from page 1 until the last page and try to implement those features one by one whereas in an agile environment, any feature the product owner feels as top priority gets implemented first. During every iteration the product owner reviews the backlog and suggests the top priority items for the team to work on.

Reason 5: Change Management

As mentioned in point 1, an FSD is usually a signed off commitment and any modifications to the FSD will require discussions and agreement between the two parties (client and service provider). Formal change management/control processes exist and are invoked when the FSD needs to be modified. Scrum on the other hand is very fluid and the product owner could just create one or more extra user stories to handle the new requirements. Of course, the product owner would need to take out some low priority items to allow the team to work on these new items but still, changes are quite easy to handle in Scrum which is yet another stark difference.

 Real Life Trivia: There are many instances where projects with a proper FSD wanted to adopt Scrum and tried to create user stories to replicate the SRS and have the team build the system incrementally. I personally was involved in one such project and trust me it was not an easy one. The 4 reasons I explained above were the main reason the project was so complicated because right from the start. In the end we managed to finish but it was more of an iterative waterfall kind of development rather than pure Scrum because many of the scrum practices had to be ignored. Reason was simple – we were constrained by a signed off FSD which did not allow us any room to negotiate whatsoever with regards to product requirements which is one of the key features of Scrum.

Some Last Words

In many organizations someone in the senior management team decides that the organization will adopt Scrum for their projects and voila people say they are doing Scrum while the reality is very different. An organization before deciding to adopt scrum needs to invest time in training its staff and getting the prerequisites ready before jumping into the scrum ocean. Trying to translate an FSD into a product backlog is one of the more frequent mistakes new adopters of scrum do and that’s why I have tried to explain why it’s not such a great idea in this article.

Do you have any good ideas to translate an FSD into a user story? Sound off in the comments section.