[openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

Doug Hellmann doug at doughellmann.com
Tue Jun 12 14:16:26 UTC 2018


Excerpts from Matt Riedemann's message of 2018-06-11 18:00:12 -0500:
> On 6/11/2018 3:31 PM, Doug Hellmann wrote:
> > As we shift teams over to Storyboard, we have another opportunity
> > to review the processes and to decide how to use the new tool. Some
> > teams with lightweight processes will be able to move directly with
> > little impact. Other teams who are doing more tracking and planning
> > will need to think about how to do that. The new tool provides some
> > flexibility, and as with any other big change in our community,
> > we're likely to see a bit of divergence before we collectively
> > discover what works and teams converge back to a more consistent
> > approach.  That's normal, expected, and desirable.
> > 
> > I recommend that people spend a little time experimenting on their
> > own before passing judgement or trying to set standards.
> > 
> > Start by looking at the features of the tool itself.  Set up a work
> > list and add some stories to it. Set up a board and see how the
> > automatic work lists help keep it up to date as the story or task
> > states change. Do the same with a manually managed board. If you
> > need a project to assign a task to because yours hasn't migrated
> > yet, use openstack/release-test.
> > 
> > Then think about the workflows you actually use -- not just the
> > ones you've been doing because that's the way the project has always
> > been managed. Think about how those workflows might translate over
> > to the new tool, based on its features. If you're not sure, ask and
> > we can see what other teams are doing or what people more familiar
> > with the tool suggest trying.
> 
> I'm reminded of something we talked about in IRC last week wrt tracking 
> blueprint-type changes over a given series / release in storyboard. It 
> was mentioned that storyboard has a not-yet-implemented epics feature 
> which is really how we'd probably do this (nested stories is another way 
> of thinking about this). So nova could, for example, have an epic for 
> Stein and then track a story for each blueprint, with the old launchpad 
> blueprint 'work items' (which we don't use, but we do have a list of 
> work items in our specs template) tracked as tasks - which would also be 
> nice since you can track tasks like documentation, CLIs (nova and OSC) 
> and tempest testing (if required). One thing people always commit to in 
> their spec is adding support for the feature in client libraries, 
> tempest and docs, but once the nova server side change is merged those 
> commitments end up getting dropped (not always, but more often than I'd 
> like).
> 

If an epic is just a list of stories, doesn't that make it a worklist?

Doug



More information about the OpenStack-dev mailing list