In Scrum or other Agile processes - how do you handle requirement versions [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

In Scrum and/or other Agile methods how do you handle versions of requirements simply? I assume that there are plenty of organisations who are Agi开发者_运维技巧le but also need to keep a track of requirement changes for regulatory purposes and so on.

You may have a requirement in version 1 which is substantially altered in version 8. How do you track that kind of change between releases?

The simple answer is: we don't, as keeping track of the changes doesn't usually make much sense or bring any benefits.

However, if for any reason you must keep track of changes (like wasteful overhead forced upon you by "regulations" - not unheard of, right?) the best thing to do is to keep your backlog in such a way that you would be able to tell how and when it did change. This is where scrum software tools can help, as doing it with a board and index cards would be a major pain. Sometimes just a simple history of all changes to any backlog item (like what we have in our Scrum tool) will suffice, sometimes you will need more complex reporting (available in some more complex tools), and sometimes you will have to produce some additional documents.

BTW - I understand "a requirement" to mean a single backlog item, usually a user story (or epic). As such those usually don't change a lot, their position on the backlog does, but usually not the stories themselves. Recording changes of stories position on the backlog doesn't make much sense in an agile project, however recording when stories were done (keeping data about past sprints) is a good practice. Recording changes to the story itself (edits, changes of attachments etc.) would be where the Scrum tool should help you if this is what you want/have to track.

You could version your requirements document(s) right along with the source code... that way, you'd have the documents that detailed the requirements at any point in time, along with the code that implements (or attempts to) those requirements.

That being said, I don't think this is any different in "agile" or "scrum" than it is in any development process.

A wiki linked to your user stories / requirements tool is probably your best bet.

We use Assembla as our main collaboration tool for our agile projects. It has a wiki where you can document your requirements and a ticketing tool that can be easily linked to the wiki (and code check-ins) through simple tags for requirements traceability.

Both the wiki and the ticketing tool keep history, so it would be easy to view and document changes over time.

As others have mentioned, from a process perspective, it's probably better to break down your requirements / stories from epics into smaller stories and ADD new stories to capture new requirements as things progress. The tool I mentioned (and I'm sure several other tools) allow you to do this easily and link the items together if you want to see how a feature progressed or was added to over time.

Why do you need to track requirement changes (I have a lot of reasons, but what problem are you trying to solve?). Do you have the option of building your product iteratively or do you need to figure most of it out up front ?

If you are able to build iteratively, I would skip requirements version management. Individual sprint deliveries will define the product at different points in time. The next sprint backlog will define committed work.

The master backlog or wish list can change as needed. It may not be necessary to track changes as the work hasn't been committed.

If you do need more control, I like Paddyslacker's recommendation of a Wiki. Most other mechanisms don't handle the relationship concepts of epics and the break down of requirements. I have always found a single file to be insufficient for complex features.

There is nothing built-on SCRUM that resembles requirement version management. That you require it may be a sign that you are either not really implementing SCRUM or that SCRUM is not the right process for you. If I had to implement something similar I would first look into your product backlog (from which detailed sprint tasks are derived) and map stories/use cases/requirements versions to them, then I would check for updates on already released items during sprint planning to see if a new "update code to match requirement" task are required for the sprint.

(I'm avoiding talking about agile as there are hundreds of agile processes out there, perhaps somebody else can give their point of view on AUP or Crystal Clear)

You didn't mention what platform you develop on but if you use TFS; it keeps track of all changes to Backlog items, when they were changed, and by whom.