How to convert specifications (from V cycle) to User stories or something more Agile ?
Hello,
Today the teams I work with asked me a simple question.
We work in a V cycle, we have framework notes, general and detailed specifications. We are asked to work in Agile,
so how to transform our specifications into user stories?
The question seems simple and it would be tempting to answer:
A/ It doesn't matter, finish this iteration in V and the next one will be more agile or
B/ We will split your specifications into stories. But there are 2 questions.
The first is that Scrum does not advocate user stories, Scrum accepts them as good practice to facilitate the understanding of the what (a persona asks for an action that brings value) which facilitates the how.
The second: Scrum is based on Lean thinking, all waste must be avoided. So cutting out specifications that are clearly written and understood by the teams makes such sense? Ideally, the teams should be asked for the solution, but for the moment it remains at the start of their agility and is firmly anchored in the old industrial paradigm. Therefore when I propose to break down the specifications in batches (a part of the spec = a functional and usable increment which is composed of several sub-parts of the spec - which individually constitute user stories - the teams seem satisfied.
Would you have any other idea?I've looked at the agile literature and surprisingly this topic doesn't seem to be covered.
How to convert specifications (from V cycle) to User stories or something more Agile ?
I'd suggest that you don't. Agile practice is about empirically learning to build the right thing at the right time. In other words, if you knew those specifications were correct enough to convert, you wouldn't need agility in the first place.
My advice is to find out why you have been "asked to work in agile". What outcomes are expected?
It's a safe assumption that, even though you have detailed specifications, those specifications will change over time. This is why plan-driven methods have rigorous change control processes in place. However, agile methods tend to recognize that change is inevitable and build change control into the normal way of working.
Someone went through the effort of creating a specification, which represents their current thinking about what the system needs to do. That's a good starting point for a Product Backlog. However, you don't need to convert the specifications into user stories. The content and structure of a Product Backlog Item is unspecified - it only needs to represent something that is needed to improve the product or service being offered.
You're already on the right path. Break down the specification into Product Backlog Items and then further refine those Product Backlog Items into smaller Product Backlog Items that are precise and detailed enough for the team to design, implement, integrate, and test and where each Product Backlog Item is something that the team can be completed within a single Sprint. As you develop the system and either demonstrate or deliver the increments to the stakeholders, they can add, remove, or suggest reordering the Product Backlog to best meet their needs. I suspect that some of the things that were in the original specification will end up removed, but that you will also find things in the specification that were incomplete or missing.
If you use user stories, please remember that the story is a card, conversation, and confirmation. The original doesn't specify "as a, I want, so that" layout.
Stories won't save the world. They're just a tool to lean on until you can have more conversations or learn a better way to write your specs.
The best thing to do is to ask the team who are implementing changes what would work with them and then press them to make it simple and less wasteful.
The V model has a lot of good stuff and the idea is sound, but the application typically ends up being heavy handed and documentation thick. If you use it with moderation, it can be good.
Look into specification by example. Better yet, get "discovery" by Seb Rose - its mind bendingly good.