Open Stack

John, thanks for your continued insights and assistance!  Please see some
of my comments in-line.

On Fri, Jul 3, 2015 at 7:09 AM, John Garbutt <john at johngarbutt.com> wrote:

> On 2 July 2015 at 22:48, Barrett, Carol L <carol.l.barrett at intel.com>
> wrote:
> > Team - I took the AR in our last team meeting to send out the user story
> prioritization criteria and approach to socializing with PTLS that we
> discussed, to get more feedback to shape the proposal. I have also take a
> swag at the next steps after we get agreement from the PTLs on the top
> priority user-stories.
>
> So I can help start the process of PTL feedback, if that helps...
>
[ST] It absolutely does... thanks again!

>
> > We discussed 3 criteria for prioritizing user stories:
> > o       Cross Project User Stories (requiring BPs in multiple projects)
>
> +1
> Helping co-ordinate these is awesome stuff.
>
> > o       Address needs of multiple market-segments (Enterprise, HPC,
> Telco, etc)
>
> I think "address key blockers to adoption" might be a better way to
> express that. But I don't have the context here.
>
> [ST] Good suggestion, this criterion is to ensure that the user stories
relevant to multiple working groups.  It will help us prioritize user
stories with overall greater community impact/value for our pilot.
Addressing key blockers to adoption is the overall objective that pursuing
user stories helps achieve.

> o       Can be implemented in M-development cycle (I have some
> reservations about this one, in that this may cause us to select less
> impactful user stories)
>
> -1
> I think having you folks prefer to track the larger efforts that span
> multiple development cycles would be more useful to me. Those are the
> things were its easy to loose track of what you were trying to fix in
> the first place.
>
> Now you totally might not want to start with those, and thats totally cool.
>

[ST]  Originally, the thought was to keep the user stories to one release
since this was only a pilot phase and we didn't want to select items that
would make the pilot extend multiple releases.  The more I am think about
this however, I agree with both of you (Carol and John), because this is
another critical part of the workflow that needs to be tested so that we
can make necessary improvements in the process of tracking efforts through
multiple releases.  If we don't have any user stories in the pilot that
span multiple releases then we are effectively not testing one (important)
part of the overall workflow and process.

The part I am struggling with is terminology since user stories are
generally completed in a single sprint.  Maybe for our group/community user
stories can span multiple releases but tasks (which would align with
blueprints/specs) will be single sprint items.  I have the action item of
documenting our taxonomy (epics, themes, user stories, tasks, etc.) and I
would be glad if you could review that document once it's published.

>
> > When all of the user stories are posted to the Repo, so that people can
> review and comment on them, we'll create a score sheet (posted to the repo
> too?) where each user-story will be scored against the above criteria. When
> the review/comment period is over, we'll review the outcome of this in a
> team meeting and select the top 3-5 user stories & Themes that we want to
> use for the M-design summit pilot. Ideally, we will have a volunteer to
> lead the analysis and design summit prep activity for each of the select
> user stories at this time.
>
> Nova has over 100 feature request (specs) in review for liberty, after
> having got around 50 merged already. Thats my way of saying we might
> need a bigger list, over time. But clearly we have to start somewhere,
> so maybe 5 or 10 is a good place to start.
>

[ST] Point taken. :)  This is just a pilot and that is why we chose such a
small number.   If the pilot goes well, and we work out the uncovered flaws
in the workflow, then we will hopefully start pursuing more user
stories/themes in parallel.

>
> > Once we have the prioritized list and our top 3-5 identified, we will
> review the entire list with the PTLs in the cross-project team meeting to
> get their feedback, and adjust priorities as needed to finalize an agreed
> upon set with the PTLs.
>
> Have you spoken to defcore folks about the interop issues they are
> identifying?
>
> I think their interop work is one of the most impactful things that is
> very cross-project (in places), and could do with some user
> perspective thinking. For example, they are looking at how does a user
> know what public IP address their VM has, and how to get that public
> IP address. Another is what does it mean to complete the list of
> images between clouds.
>
> [ST] Rocky G. brought up the interop items at our last WG meeting.  I took
the action item of going back and looking at the exchange that occurred on
both of the topics and trying to build user stories that capture the
requests.  There is probably an opportunity for DefCore and Product WG to
collaborate going forward.  I will be at the DefCore mid-cycle and will
discuss the user stories with them if time permits.  I think it is too late
for me to get something on the agenda itself although I will certainly ask.

> Next this team will need to determine what CPLs we want to establish and
> recruit volunteers. From there, the User Story owner will work with the
> CPLs and others to analyze the user story, identify gaps, develop BPs and
> develop an implementation tracker.
> >
> > Pls send your thoughts to improve the approach to this ML and we can
> discuss/finalize (hopefully) in our next team meeting.
>
> I think it would be good to have some context for these user stories,
> like some common descriptions of our users. (I know the UX folks are
> building personas, I have lost touch with that process). I think just
> some very basic stuff, would be a good start.
>
> [ST] Another great idea.  We will need personas as a part of the user
stories since each one begins with "as a <actor/role>" which is essentially
a persona.  I will try to get in touch with UX to see if they have a list
of personas that they can share with our team.  It might make sense to
include this information in the taxonomy document I mentioned earlier.


> Like we talk about deployment scenarios:
>
> Micro cloud:
> single type of user (Deployer and Service user, self-service debug)
>
> Larger public or private cloud:
> Operator/Deployer/Administrator (deploys and maintains)
> Service user group Admin (use APIs, horizon)
> Service user group Member (use APIs, horizon)
> Support (partial admin that helps users)
>
> The other thing is maybe basic types of Service users, something like:
> * cloud native app, bootstrapping
> * cloud native app, backing
> * dev/test and CI environments
> * running pets in the cloud, used to traditional server virt
> * hybrid solution (mix VMs and trove, or VMs and external systems, etc)
> * ... etc, etc
>
[ST] Are these service user types documented anywhere by the Nova team?  I
would be interested in looking at the list.  Some of this information might
come out in the user story (although not explicitly).  When we document a
user story the objective and reasoning/value sections might give hints as
to which type of service user the story applies to.  I wonder if it would
be helpful to document this somewhere in the template beyond just trying to
decipher it from the user story itself.

>
> Now thats totally Nova focused, but hopefully that gives some ideas
> about what I am think
>
> Thanks,
> John
>
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time