[Product] User Story Template

Steve Gordon sgordon at redhat.com
Mon Jul 6 19:18:08 UTC 2015


----- Original Message -----
> From: "Shamail Tahir" <itzshamail at gmail.com>
> To: "Steve Gordon" <sgordon at redhat.com>
> 
> On Fri, Jul 3, 2015 at 2:32 PM, Steve Gordon <sgordon at redhat.com> wrote:
> 
> > ----- Original Message -----
> > > From: "Shamail Tahir" <itzshamail at gmail.com>
> > > To: product-wg at lists.openstack.org
> > >
> > > Hi everyone,
> > >
> > > I had taken an action item (a couple of weeks ago) of updating our user
> > > story template to align it with our intended objective of providing a
> > > simple way to capture high-level feature/enhancement requests in the form
> > > of user stories.
> > >
> > > Our intention is to share user stories with the project teams and the
> > > project teams (if they choose to move forward with a submitted user
> > story),
> > > as always, will determine the technical implementation that best suits
> > > their service architecture.  The primary data being documented via the
> > > template is who, what, and why (not how).
> > >
> > > The current template we were planning to use has the following sections:
> > >
> > >    - Glossary
> > >    - Problem Description
> > >    - Affected By
> > >    - Requirements
> > >    - Related Use-Cases
> > >    - Gaps
> > >    - References
> > >
> > > This template was developed by the Telco-WG and we chose to adopt it as
> > > well.  The template actually goes above and beyond what we would need to
> > > capture the necessary data for user stories (i.e. it includes sections to
> > > document implementation details).
> >
> > Hi Shamail,
> >
> > Can you elaborate a little here? We made an explicit decision in the telco
> > working group *not* to include implementation details in the template or
> > the proposals that use it so I'm wondering which sections you see as
> > representing this (particularly as all the major sections are repeated
> > below albeit with different layering - e.g. in the telco template the user
> > stories are part of the problem description [1])?
> >
> > Thanks,
> >
> > Steve
> >
> > [1]
> > http://git.openstack.org/cgit/stackforge/telcowg-usecases/tree/template.rst
> 
> 
> Hi Steve,
> 
> Thanks for reviewing the proposal.  The sections that led me to believe
> that there would be implementation details in the telco-WG template were
> the "affected by" and "requirements" sections.
> 
> The affected by section contains the following description:
> "*If you are aware of any work in progress that will affect this use case,*
> *please list it here.  Include links to a spec or blueprint or bug report*
> *where applicable.*"
> 
> The requirements section contains the following description:
> 
> "*Use this section to define the functions that must be available or any
> specific technical requirements that exist in order to successfully
> support your use case. If there are requirements that are external
> to OpenStack, note them as such. Please always add a comprehensible *
> 
> *description to ensure that people understand your need.*"
> 
> In my view, it wouldn't be possible to fill out either of those sections
> without having some technical solution in mind.  While it may not be
> explicit implementation details, it would require the author to at least
> have some architecture in mind on how to approach the problem.  I was
> imagining the demarkation to occur before this point (i.e. we share user
> story and if the team(s) decide to pursue them then they we would break it
> into tasks/blueprints).  There is probably some technical solution in mind
> by the time we get to the blueprint submission phase but not necessarily
> when the user story is provided.  I also noticed that the template you
> linked[1] is different from the version that we had been using[2].  The
> older version[2] did not contain a user story section.

The first gaps section is simply ceding of reality. Often times there will be an existing proposal that touches on the use case, if the user already knows of such proposals we have them fill them in. It's non-mandatory, those that don't know leave it blank.

On the requirements front, please recall that in the telco at least on the NFV front our use cases themselves are typically complex applications with known expectations/requirements of the infrastructure. This is what the submitter is being asked to list - effectively how is the application implemented, not implementation specifics on the OpenStack side.

My concern with what's being proposed here is that as I understood it in the ideal state the other working groups including telco would feed use cases to the product working group, which would then feed them to the projects. This proposal seems to indicate that as part of that the product working group will be endeavoring to turn what we're producing into something with *less* fidelity rather than more - effectively removing some of what we're documenting, at which point I'm not sure of the benefit to the other working groups (e.g. telco)?

-Steve

> I agree that the sections between the telco-wg template and the proposed
> one are very similar.  The perceived difference may be how the sections are
> being used.  Please let me know if our perception is incorrect about how
> implementation/architecture specific the telco-wg template is intended to
> be.  It would be ideal if we could use the same template and, at a minimum,
> we need to ensure that we leverage the version you provided [1] instead of
> the one in google drive [2].
> 
> Thanks,
> Shamail
> 
> [1]
> http://git.openstack.org/cgit/stackforge/telcowg-usecases/tree/template.rst
> [2]
> https://docs.google.com/document/d/1mO6fjmvDRvppoRqDSfWdDW2p3G9ESKSgI9cxRP4mvB4/edit
> 
> 
> > > I would like to propose an alternate
> > > template that removes the extra items and replaces them with some of the
> > > meta-data that we will need for organizing user stories.  The end-goal
> > > being to keep it simple while being able to accommodate the necessary
> > > information.
> > >
> > > Proposed template sections:
> > >
> > >    - Theme (equivalent to an epic)
> > >    - Parent theme (would we allow multiple?) this user story is
> > associated
> > >       with
> > >    - Interested Working Group(s)
> > >    - Working groups that support this user story as being important to
> > >       their market segment/area of focus (multiple groups can support the
> > >       same
> > >       user story to eliminate duplicates)
> > >    - User Story (in standard user story format of "as a <role/actor>, I
> > >    want to be able to <objective> so that <reason/benefit>")
> > >    - Standard user story formatted entry
> > >    - Problem Description
> > >    - Optional.  This section an be used to provide additional details
> > about
> > >       the problem or why it needs to be resolved (e.g. enables a new
> > workload
> > >       type to be supported, reduces barrier to entry, etc.)
> > >    - Gaps
> > >    - This section documents which services would be involved in
> > completing
> > >       the user story (e.g. nova, cinder, etc.)
> > >    - Blueprints submitted to complete this user story
> > >    - This section is to be filled out later.  It would act as a
> > centralized
> > >       tracker for all blueprints that were generated to complete this
> > > user story.
> > >    - References
> > >    - This section could include other documents that expand upon the user
> > >       story.  For example, Telco-WG could link their use case entry
> > > that would be
> > >       associated with this user story in this section.
> > >
> > >
> > > Please provide feedback and let's discuss if we should stick with the
> > > original template we were planning to use, move forward with the sections
> > > proposed in this message instead, or if you have a simpler way that we
> > > could organize the template while collecting the necessary information
> > and
> > > metadata.
> >
> 
> 
> 
> --
> Thanks,
> Shamail Tahir
> t: @ShamailXD
> tz: Eastern Time
> 

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform



More information about the Product-wg mailing list