Re: How to handle Release Rollbacks

[MikeD]

HI Dan,

Are you using an integration that is allowing there to be noted on
stories in what release they went out?

If not, then from a planning point of view you would have had to done
replanning and reallocated the stories to a different release (which
is a child project in the V1 project hierarchy).
By doing this then reporting would reflect correctly in which
'release' a story was actually delivered.

Note that some teams that decouple their development cadence from
their release cadence will have a custom field that allows them to
indicate what release a story actually was 'shipped' in.

If you could provide a bit more info, that would be helpful.

Cheers,

Mike

On Jul 20, 1:20 pm, Dan <ddematt...@q.com> wrote:
> We recently had to rollback a Release due to infrastructure problems and
> deploy it at a later date under a different Release number.  Does anyone
> have any suggestions on how to handle this in VersionOne?  Specifically I'd
> like to be able to call up the first release and find out from the backlog
> what was released then - and call up the second re-release and find out
> from the backlog what was released at that time.
>
> Thanks

[ddema...@q.com]

Thanks, Mike.

Basically we list each potential release as a project and split user stories if the work spans 2 releases/projects. It's worked beautifully up to this point. What do you think about splitting the user story so that the work is in the "release" it is done in and the deployment is in the 'release' is was delivered in?

Dan

--
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.

[MikeD]

In VersionOne, the split functionality is associated with Sprints /
Iterations. If you were to split a story and then take the new story
that was generated along with the remaining task / acceptance tests
and move that into a different project, that should work out fine.
Do you have separate tasks for work that is done in your deployment
process? Is deployment part of the definition of done for a story?
Kind of sounds like it is if each story needs to be identified to the
release in which it goes out. Keep in mind that splitting a story
that has no outstanding work wouldn't make sense.

Last queston for now, do the projects all share the same "Sprint
Schedule" in VersionOne?

Cheers,

Mike