Story Gathering Workshops
Hello everybody,
I have some questions about story gathering workshops as there are little notes and explanation on different sources.
I would be grateful if you share your valuable information with me.
who should attend these workshops?
what are the best ways of capturing these stories?
which level of detail is appropriate, shall we define acceptance criteria in this workshop?
Thanks so much
Have a look at the Scrum Guide and what it has to say about Product Backlog refinement. Would the "story gathering workshops" you refer to be a means of achieving that? What does the Guide say about who should attend?
Hi Ian,
thanks for your reply I know in backlog refinement PO and development get together and work on details and estimation and ordering of backlog but for the first time when the product backlog is not created yet, shall we invite the development team. should the product owner invite key stakeholders? what about the scrum master?
If the Development team aren't involved in crafting the Product Backlog, there can be no assurance that they understand the content.
If the Product Owner brings in other stakeholders, can it really be said that the PO is competent to represent them and their interests?
If the Scrum Master isn't there, will the team understand how to create the backlog and how to make the best use of Scrum?
I would say that this 'story gathering' workshop might be a good practice for collecting the needs and views of stakeholders. I don't agree with Ian that this would necessarily imply that the PO does not represent their interests, it's just not a Product Backlog refinement session as that by definition happens between the Scrum team. The PO has the last say over the Product backlog but as long as that is not in question, it might be quite productive to have extra customer input.
I think this is something that is not described in the Scrum guide because it happens outside what is described in the Scrum guide.
> I think this is something that is not described
> in the Scrum guide because it happens
> outside what is described in the Scrum guide.
That is essentially correct, and therefore the best course of action is to evidence an ability to implement the framework.
Assurances to be demonstrated include a team understanding of any proposed backlog, the ability of the Product Owner to represent stakeholder interests, and the availability of a Scrum Master who can coach the team and fulfil the servant leadership role.
Another option can be to immediately commence sprinting, and to create enough of a Product Backlog during Sprint Planning to allow the first Sprint Backlog to be forecast. An empty Product Backlog is not necessarily a contra-indication to sprint entry.
I found this 3 part blog post from Stephan van Rooden to be very helpful on the finer points of PB refinement, adding some tips for the PO and info the SM can share with PO. If feel that Stephan's tips still fit inside the Scrum Guide
Specific to your question, Stephan includes a description of some called "Magic Estimation", which provides insights into who should be involved in which parts of the PB refinement. I could see a PO using this "Magic Estimation" game concept to create an initial product backlog. I'm speaking of concepts from "Magic Estimation", not literal "use it". As an SM, I would share this information with the PO, have a Q&A about it, then offer to help/support/coach the PO on steps she may want to execute to create that initial product backlog.
Link is here: http://blog.scrum.org/product-backlog-refinement-explained-13/
What is we keep this story gathering workshop separate from the backlog refinement. The story gathering may be out of Scrum and PO can do it along with his/her stakeholders. Once he has the list from his/her users then he can put them in the backlog, order them and refine them further along with development team.
There should be a first level acceptance criteria defined for each item that can be updated in the refinement meeting.