We are starting to use a Scrum process for development. We have a nice stack of user stories now . I'm wondering though, once a user story is complete, tested and deployed do you do anything else with it? We're using little index cards right now, I'd think it would be fine to just toss them in the trash can.
If you keep them, what do you do with them later?
Archive them for reference on future projects. They will be useful when you have to estimate story points. Often times, similar-sounding stories occur across projects.
Um - keep them and put them in the project file. CYA in all cases. You never know when a client will come back and ask you "why is this this way?", or "who decided that was how it was?". You can then pull out the user story and have backup.
Always keep everything like this until the warranty period has expired on your software... unless you want to be put in the position where you could be asked to "fix" something that was really a change for free.
PEZ is almost right. Recycle the cards rather than trash them. :)
There really is no point in keeping them. If you need a history of changes you can get that from your SCM and test scripts.
Another vote for keeping them. I know it's a dirty word, but the user stories are part of your documentation, and serve an important purpose.
Three years from now when you (or the inheritor) are making changes to the system it's helpful to have the historic documents to know why you did things the way you did.
It also helps when the situation changes and you have to rewrite to be able to go back over the user stories that the application satisfies and determine whether or not those same stories apply to the new version.
I usually wrap each iterations worth of user stories (and tasks) in a rubber band and a new card in front stating the velocity and estimated points. I've never had any use for them though, except for nostalgic reasing. So keep them for the archive I'd say :-9
Hang on to them!
I write requirements (rather than code), but I frequently find myself rereading old user stories and acceptance tests (mine and others').
Reviewing old stories can help me find the clearest phrasing for complicated concepts, rather than reinventing the wheel. They sometimes serve as a useful reminder for details I might otherwise forget to document. Stories written by others help me come up to speed on features I wasn't involved in, and will probably be a good learning tool for new hires.
I could go on, but let me just put it this way:
Which is more likely to cause greater problems -- keeping the stories and not needing them, or needing the stories and not having them?
Keep them (archive them) so that if there is a dispute or argument over something in the future, you have a reference to it, and can cover yourself.
Completed user stories are essentially the final specification for your project. If you started with a formal requirements document or specification, there are many lessons to be learned by comparing your completed user stories with that document. If you don't have an initial document, then your completed user stories document the functionality of your project. In either case, I think it's very valuable to hang on to them for future reference, whether in project post-mortems or when estimating and planning subsequent projects.
I find that we never know what's going to be useful in the future, so my recommendation is to tag them and file them. If you're using physical cards, scan them then do something as simple as adding a tag to the image file. Imagine looking at a tag cloud later to find common threads or to locate and re-use your content.
As with all things scrum, though, if it starts taking too much time, it's probably not worth your effort. Don't make it a crazy process, just quickly file it and forget it.
Cheers, Reeves
© 2022 - 2024 — McMap. All rights reserved.
