Who can add users stories? Who's responsible for ensuring user stories are ready? When do we work on user stories? How much time should be spent, and by whom? How much information is needed in a user story?
What does the Agile Manifesto state ... Nothing. User stories are not part of Agile ... (smile) ; however they are a well known and trusted mechanism for capturing requirements .. so let's go with that!
Let's first define what we mean by a user story:
A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.
A user story should satisfy an agreed "definition of ready"; which should contain enough information so that the team can estimate it, but sufficient enough unknowns so that the developers can work with the business, SMEs, each other etc as a user "story" is meant to represent an ongoing and evolving conversation with stakeholders, and not a fixed specification!!
And also what does the Agile Manifesto does say about working as a team;
Business people and developers must work together daily throughout the project. -The Agile Manifesto
The best architectures, requirements, and designs emerge from self-organizing teams - The Agile Manifesto
Let's bear that in mind these definitions as we progress.
This one should be simple enough.
Answer 1: Anyone
And I mean anyone - adding stories to a backlog does not constitute to anything being worked on - that all comes later.
Again this one's easy.
Answer 2: The Product Owner.
The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
Answer 3: All the time.
So; this is starting to raise more questions (or it should (smile)) - if anyone can add stories, but the Product Owner is responsible for them, and we can work on stories at any time - who actually does the work; does the product owner need to do all the work to get stories into a state in which the team can work on them, in isolation?!
Let's take a look at what the Scrum Guide says on this ....
From the ScrumGuide:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Answer 4: The whole team
Stand to reason - if a business analyst or product owner is the only one working to write user stories, this creates an artificial dependency and will cause bottlenecks always waiting for user stories to either be written or refined.
The team will always have valuable input for the product owner or business analyst to add to the user stories and can write their own. The authority of what user stories get worked should rest with the product owner, but as far as writing the actual stories, this should be a shared responsibility amongst the entire team.
But here we need to add more clarity - The whole team, including stakeholders, need to collaborate on them, but we don't want to break our sprint by the whole team only writing stories. So how much time?
Answer 4 (part 2): From Scrum Guide we see the delivery team : <10% (Half a day a week) - Product Owner: 100%. (Also business analysts - 100%)
For a typical scrum, with well good that makes sense, the team are focused on delivery, working on stories in the sprint, delivering on commitment.
This tho' raises another question - what about complex stories that the product owner/business analysts can't progress and need input that would exceed the 10% commitment from the team?
Answer 4 (part 3): In this case, the team would need to be given time to work on this. The correct way to do this would be to add a story into a sprint, that clearly defines the work to be done - these are called "enabler stories" - and while needn't be written in the user voice, their acceptance criteria must clarify the requirements and support testing.
Answer 5: We defined this at the start ... just enough! (smile)
What is just enough will vary from team to team - but remember a user story is NOT a specification, it's not a solution - it needs to speak in terms out outcome and valueless is perhaps more in this case!