Help a PO writing User Stories

There's nothing that says you can't delegate this responsibility to the Development Team; but hopefully you are part of a collaborative Scrum Team, and you'll collectively find a way that works best for the team.

It's quite normal for a Product Backlog Item to be continuously split in order to separate out complexities that might not be needed right away, would delay getting feedback on other functionality, or would just make the initial implementation too complex. In my opinion, it doesn't matter who triggers the splitting and even who would update the backlog, so long as you remain in a position to be accountable for it.

I personally like the CRUD approach, and I normally suggest that Development Teams implement the Read scenario first.

They might need to manually set up data for it to work, but it would already allow feedback to be gathered from the moment that one item is released. After that, create, delete and update could be added.

It might be that you or the team split these stories further, for instance to only support the simplest or most useful use case in the beginning.

Do your team use metrics? Understanding the cycle time and flow efficiency could be very useful in measuring whether a new approach has the desired effect.

Splitting stories is generally worth trying, but it's hard to get it right. It's good for the team to experiment and find what works best. It might be that this initiative requires an altogether different approach from the team, such as more carefully managing the dependencies between items, and communicating effectively about their plan for completing the work.

Regarding the decisions that the Development Team expect from you, have you tried asking them to use their judgement? Maybe they're worried about making mistakes, but if you're happy for them to do their best, and understand that they will probably make some choices that you don't like, perhaps you just need to set the right expectations. A lot of teams thrive with the extra autonomy. But perhaps they lack the necessary skills to do what you want. It could be another thing to experiment with.

Agree with Simon's advice.   A couple other things to consider:

- Perhaps Ron Jeffries would not approve of how you are approaching User stories, but keep in mind that Scrum is not prescriptive at all about this.   You don't need to use User Stories to capture requirements.   The Scrum Guide simply calls items in the Product Backlog "items".   

Whatever works well for you and the Development Team is what you should use

- It is a good thing that your Development Team is reaching out to you for clarification regarding some of the needed functionality.   These requests for clarification sound like excellent candidates to split out into separate items.   

What is most critical is to have the conversation between you and the Development Team regarding these questions, and to have someone capture the details and outcomes from such conversations 

@Simon Mayer mentioned a lot of things I had in mind so I'll just elaborate/reiterate a couple.  

The Product Owner is responsible for managing the Product Backlog but that doesn't mean they are the only ones to update it.  Some of the things your team is asking you to do could probably be done better by them.  It sounds like you are giving them a good business level set of stories.  I would suggest that you ask them to provide the technical details.  Have them own the technology implementation and let them know that you are ok with their decisions in that regard.  Providing a list of fields and the rules around their validation is definitely within the business domain. How the application undertakes that validation and presents it to the user is within the technical realm.  

I am also a fan of taking the CRUD route.  And like @Simon Mayer, I often start with the Read portion. It means that the technical solution for that part requires database design, UI design and thought about how the work will flow.  It allows for feedback on the data elements, the data display and lends well to discussion on how the user will want to update data. And each part of CRUD is potentially releasable. 

Now they want me decide and write down if I want to block the date selection to a valid date (not overlapping another suspension, only allow to select a date after the contract start and before its ending), error messages that I want the user to see, what to do when I delete a suspension. I get the feeling that all of this would be dev team’s work, not PO’s.

A technique to try is turn those questions back on them.  "What do you think makes sense in <blah blah> case?"  Have them start recommending solutions that you can accept rather than you dictating to them.  Get them comfortable with providing ideas and even more comfortable with you accepting their ideas.  Be blunt and say "I am not sure how to do this just that it needs to be done. How do you feel it can be accomplished?".  Then be willing to accept their ideas and let them proceed. 

A lot of times the situation you described is because of a lack of trust, whether real or imagined.  They may have been burned by this in the past and are afraid to venture forward because of it.  Help them see that you trust their judgement by asking for and accepting their input. 

What would you do in my place?

I’d ask the Scrum Master to help coach the team about the purpose and value of user stories. A good team ought to be able to take a non-technical story and, through refinement, understand its technical implications sufficiently well to estimate it and meet the INVEST criteria. 

I won't rewrite previous great comments. IMHO there is not silver bullets, sometimes slicing PBI by CRUD will be appropriate, sometimes not. I would try to write some Acceptance Criteria in Gherkin model - it really helps with refining our thoughts and find hidden PBIs.



Try different things as a Team and find your unique way of working ;)

Thanks for all the replies.

It's nice to know that you think that way and I really think that the big problem right now is that they are a new dev team that's working on an existing product and don't have the confidence to make their own decisions right now.

One thing that keeps bugging me about the CRUD approach is that maybe some stories end up not being independent and to me it gets harder to define a sprint goal that is not something like "implement this 4 stories".

@Simon Mayer, which metrics would you suggest? Right now we are only using burndown. I used to work with CFD. Would you recommend it?