User Story issue - Who is this for?

[Michael Grumbach]

I'm a Scrum Master for an IT Platform team.

It seems like a lot of the work we do is not directly for the "customer" and I need a better way to write the "As a ..." part so that our User Stories have better focus.

Examples:

As a Platform Team Member, I want to add issues found after POS373 to POS377, so that register issues are healed

 - This user story is about adding production ready code to a package which will be pushed out to store registers.

 - The beneficiary of our work is the clerk at the store who uses the register, but lots of the things we do are behind the scenes, not something on the GUI or functionality the clerk is aware of.

I could change alot of these user stories to, "As a register user, ...", but it seemed a little ambiguous.

Example:

As a Platform Team Member, I want to be able to use the production DB, so that we can benefit from the backup and recovery process

 - This user story is about changing the pointers from the test to the production DB

 - This will aid our team in the event of a server failure

 - So maybe the "Platform Team Member" user is ok here?

We're currently working with the following:

Example:

ASW wants to understand why POS is not launching, I want to increase the log retention, for improved register health

- So the customer is a description of who would care about what this work will produce

- Seems reasonable, but wondering what other folks are doing.

Thanks.

[miked]

As platform team member,
I want to meet the need of the people on the other side of the display,
So I can continue to be satisified in my work, add value to the services, applications,and products that rely on this platform,
So that the users of services, applications, and products prefer our approach over other options available to them.
I know this is done when
1. We need to enhance existing platform capabilities to meet demand
2. We need to deliver new platform capabilities to satisfy new customer expectations.
3. We need to refine existing platform deliverables to meet customer improved understanding of what they value.

[Mark Levison]

Michael - this only just landed in my inbox today. How strange. Mike D. has done a good job trying to solve the local problem.

However Scrum has helped you sense a systemic issue. Your teams may well be misaligned. Better (in most circumstances) is to have Feature Teams - see: https://www.infoq.com/articles/scaling-lean-agile-feature-teams and then you side step the problem because each team is capable of producing work/features independantly. There is infinitely more depth than I can cover here, flying in about a minute. The InfoQ article and accompanying book chapter cover it well.

Cheers

Mark 

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--

Mark Levison | 1 (877) 248-8277 | Twitter | LinkedIn | Facebook Certified ScrumMaster Training: Vancouver | Edmonton | Ottawa | Montreal | Toronto Certified Product Owner & Private Training also available ~ Our Training Schedule Agile Pain Relief Consulting | Notes from a Tool User Proud Sponsor of Agile Tour Gatineau Ottawa and Agile Coach Camp Canada