From VersionOne Backlog to a printed requirements document

[joelsanda]

Hey group,

We just adopted VersionOne and some of us are arguing for writing all
requirements in VersionOne while some call for writing the
requirements in a separate document and copying/pasting from that
document into VersionOne to create backlog items.

The biggest impasse we're currently having is this:

Exporting backlog items from VersionOne into MS Word so we can store/
print a requirements document. Here's a use case describing what we'd
like to do:

1. Backlog items entered into VersionOne.
2. After a sprint is complete that sprint's user stories are exported
into MS Word requirements document.
3. Requirements document is managed in Word for consumption in that
format.
4. Rinse and repeat after each sprint.

Anyone doing this or something like this now? Any gotchas or success
stories someone can share? Do we have to customize a view and pull
user stories out in .xls format and massage into the desired .doc
format?

Thanks for any help!

- joel

--
You received this message because you are subscribed to the Google Groups "VersionOne-users" group.
To post to this group, send email to versiono...@googlegroups.com.
To unsubscribe from this group, send email to versionone-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/versionone-users?hl=en.

[Karen Cook]

HI,
I'm interested in how the group responds. I know you can take the
stories into Excel easily (which you could then port to Word) but that
only includes the story and task titles, not all the descriptive info.
Any ideas?

Karen

[NK the BA]

Hi Joel,
We've been using Version One for about two years on different
projects. While everyone loves the requirements being in one place, I
find that using a separate lightweight requirements management tool
with traceability works much better. It will be easier to maintain
requirements, trust me, we've tried a lot of different ways.

So the process would be something like this:
1 - Create User Stories with unique numbers in Wiki (one wiki page per
story, ie 01-01 As a User I want to view my bills) - Sharepoint is a
good pick if you have it. You can then do an RSS feed of all the wiki
pages in a library and make a Word document from that.
2 - Associate mockups or wireframes to the stories in the wiki (either
inline or if using Sharepoint, as related images in the photo library)
3 - Create Backlog Items in V1 and map the BIs to the Stories in your
wiki using a custom field "Story" and I like to name the BI with the
Story ID leading the BI Title. (you can also put the URL to the story
in the description)
4 - BA can easily keep stories up to date in wiki, Developers know
where to go for requirements
5 - Easy copy and paste into Word from RSS feed when you are done.

By the way there are papers on the web that discuss benefits of wiki
requirements. Let me know if you need me to point you to a good one to
support your case.

Good luck,
NK

[joelsanda]

NK,

Thanks for the feedback. I've done requirements with a wiki before -
in fact managed nearly all my QA group's testing activities and the IT
infrastructure that way. Worked like a charm.

Was there something in particular that made it rough managing the
requirements in VersionOne? I can immediately see the need to update
the user stories in VersionOne if the requirements are managed in a
source external to VersionOne - you'll have to code up a connector
with the API or manually copy and paste.

Thanks!

- joel

[Roux, Julie]

Joel -
This is something we're currently wrestling with as well. We came to
the decision to *almost* completely re-write our requirements in the
requirements management system we use (HP Quality Center) after we've
progressed to an integration testing/stabilization iteration. We
arrived at this decision after considering the following:
1. We (and those outside our teams) frequently refer back to our
biz+functional requirements for: support, training or "how does that
work again?" scenarios.
2. We don't want to turn stories into requirements documents. Our
stories do contain detailed acceptance criteria, but we want to treat
our stories as we think the methodology meant them to be treated (as
delta-type documents for a given iteration). This means that a story in
iteration 2 may supersede a story in iteration 1. Therefore, if our
stories were exported into "requirements" someone doing research would
find a lot of contradiction - not good.
4. We love change and know that our process must enable it. Per the
above we thought that if we started to treat stories as requirements
documents we would lose all the good things we had hoped to gain for the
project team and slowly migrate back to a waterfall way of doing things.

5. We really have it out for our analysts ;). On our teams our analysts
play the product owner (proxy) and unfortunately will have to perform
all the duties of that role as well as define the "final" requirements
in our requirements management system too. We know that we've reduced
our velocity by deciding to do things this way, but until our system(s)
documentation plays less of a role in support, training, etc we're
saddled with this process.

We are starting to pilot this process on a couple of teams to see how it
goes. Let me know if you'd like to be kept in the loop. I'm sure we'll
learn some lessons along the way.

Thank you,
Julie

-----Original Message-----
From: versiono...@googlegroups.com
[mailto:versiono...@googlegroups.com] On Behalf Of joelsanda
Sent: Monday, April 26, 2010 5:20 PM
To: VersionOne-users
Subject: From VersionOne Backlog to a printed requirements document

[NK the BA]

The key is NOT to put the requirements into VersionOne. They don't
need to be there. Developers (and people in general) are smart enough
to find the requirements in the wiki or other source as long as the
relationship and location is clear.

Negatives for managing requirements in V1:
# There is a lot of overhead in opening each BI and updating
requirements.
# There is little ability to format - the little format that does
exist will not translate nicely from v1 to excel to word.
# There is little ability to see the big picture.
# BIs for functional requirements vs other System BIs are intertwined
(depending on how you decide to create your BIs)
# It is not a pleasurable place to hang out and create requirements
(no flow).

> For more options, visit this group athttp://groups.google.com/group/versionone-users?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Joel Sanda]

Thanks for the input, Julie. I was concerned about the maintenance of two sources of information for development and QA: requirements documents and user stories. But, your ideas, combined with suggestions from NK the BA, are making a compelling argument for separating the two.

I'm still a little uncertain about having two sources of 'stuff to do', but you guys are helping me understand the issues with managing all requirements and user stories in VersionOne.

[Thompson, Richard(LIT)]

We are also storing our "requirements" in Quality Center (use cases and
business rules) - and putting our stories in V1.

Julie - I would be interested to know how you are structuring your
requirements in QC as this is an area we are trying to streamline.

[Mark]

This might be moving the discussion a little more towards a process
issue rather than V1 but, here goes. I also would like to single
source the documentation so I started with listing requirements in V1
BL with stories. Some requirements becomes stories in themselves
(small ones) and others are more like place holders. The latter get
closed when all the stories that implement the requirement completely
are accepted (usually takes multiple stories/sprints to fully
complete). I'm not really liking this approach. If I was to keep all
requirements outside of V1, then we would have to have traceability
(company process mandates) from each requirement back to what tests
(and implicitly stories) map to a given requirement and show that the
requirement was implemented fully and tested to show the same. I could
imagine including some unique requirement ID in the external document
and pointing any story that implements that requirement to that same
ID (using the story reference field). By inclusion, all tests that are
part of all stories that implement a given requirement provide the
traceability needed.

Has anyone else grappled which such a need - using V1 + some external
requirement traceability - and you you care to share your thoughts and
suggestions?

Thanks,
Mark

On Apr 27, 5:09 pm, "Thompson, Richard(LIT)" <R.Thomp...@Liberty-

> For more options, visit this group athttp://groups.google.com/group/versionone-users?hl=en.

>
> --
> You received this message because you are subscribed to the Google
> Groups "VersionOne-users" group.
> To post to this group, send email to versiono...@googlegroups.com.
> To unsubscribe from this group, send email to
> versionone-use...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/versionone-users?hl=en.

>
> --
> You received this message because you are subscribed to the Google Groups "VersionOne-users" group.
> To post to this group, send email to versiono...@googlegroups.com.
> To unsubscribe from this group, send email to versionone-use...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/versionone-users?hl=en.

[Steven Ropa]

I've been lurking for a little while here, and as we see the discussion morph into more of the process discussion, which is a good thing, I feel maybe I can contribute a little now...

My first response is that it seems like the extra movement to some other requirements management arena seriously stifles the agility of the process. It has a feel of "ok, you can do your agile thing, but don't change anything either".

One thought that might be little more useful: Have you thought about using Feature Groups, Goals, Themes and Epics to manage your higher level requirements? The idea would be to be tracking all of these things in one place. This would also provide the necessary traceability.

Steve

[Darrell Piatt]

The V1 stories help you see how you got where you are, one step at a time. It tells the tale of the journey, including the detours and setbacks (defects) along the way. It is sometimes hard to digest all this into a complete understanding of the product as it currently stands. You might have to piece a lot of backlog items together in order to understand something.

For more complex systems, I can see the value of a comprehensive well-organized requirements doc that is easier to grasp and reference. It might have to be a separate artifact or Wiki area maintained by the Business Analyst as stories are defined. And the stories can reference it as needed, instead of duplicating the content.

[Steven Ropa]

Hi Darrell,

I can certainly understand the need to simplify the "story of us" for the software. I am wondering if the rollup to the level of Goals or Feature Groups would provide that simplicity?

At the end of the day, what is important is to have the right amount of documentation and requirements for your team. I imagine that there is a way to provide interactions between the requirements management docs or systems and Version One, using the SDK. I myself am going to look into writing an Office Add-in for that functionality, if I can ever find two minutes to rub together!

[Roux, Julie]

Darrel,
You hit the nail on the head (for my situation anyway). To Steven's point about organizations "wanting to do agile, but not really change anything", we considered how the questions from (downstream) teams, production defect support, stakeholders, etc would affect our velocity if we weren't going to produce this documentation. We believe that we will spend more time providing this support if we don't produce some sort of requirements documentation.

In terms of how we are setting up Quality Center, we have decided to manage a set of Product vs. Delta requirements (on the pilot teams) and have structured folders in quality center to support the "feature areas" of each system. We are going to use baselines to convey how the requirements have evolved over time. Since the requirements won't get entered into QC until after the acceptance tests have been authored we will likely just trace tests (to requirements) which will be promoted to a regression set. Having this trace relationship on a set of product requirements also gives us a good idea of how well our regression set covers a given system's requirements.