Standups, Retrospectives, and Showcases are commonly known Agile ceremonies. But have you heard about Story Card workshops? The concept of holding a workshop to talk about the specific requirements for each Story Card or User Story makes sense. However, this workshop is not called out specifically in some of the formal Agile methodologies like Scrum. So how do they work, and what is the benefit of running a workshop just for Story Cards?
Throughout this blog I’m hoping to provide an introduction to this ceremony and also explain a helpful Requirements Elicitation technique that I have been using recently.
What is a story card workshop?
Let’s start with the very basics. What is a Story Card workshop? The aim of the Story Card workshop is to discuss Stories either for the current or upcoming Iteration/s to understand what the requirements are and what needs to be done for this Story to be considered completed. These workshops are normally facilitated by a Business Analyst and will involve all members of the team (i.e. Developers, Testers, Product Managers/Business Subject Matter Experts, etc). The intention of involving all team members is to ensure they are involved in the work they will be doing. They can discuss aspects of Stories from their own perspective, which no one else may have thought of.
When do you run a story card workshop?
Story Card workshops are primarily run once the project or initiative has been incepted. This means that the project is in the delivery phase and will have a Project Backlog of Stories. The workshop will occur throughout each Iteration and is normally scheduled based on what the Business Analyst’s preference is. However, it is important to take into account the team’s approach to working with Stories. Some teams prefer Story Cards to have all Acceptance Criteria detailed before starting an Iteration. Some teams prefer to go straight from a Story Card workshop into developing the Story. The former approach would mean that Story Card workshops would occur near to the end of the previous Iteration. The latter approach would mean that the workshop occurs at the very start of the Iteration.
Process flow of how a Story evolves from Project Inception to the workshop
What needs to be prepared prior to starting your story card workshop?
Before starting a Story Card workshop there are a few items that should be completed. The assumption is that there is a Project Backlog that has been prioritised. The Project Backlog will normally be formed when incepting the project. The Project Inception aims to come up with all the Stories required for the next release/s or the entire project. They will normally be prioritised with the assistance of the Product Manager.
If all of this has occurred, the Business Analyst will select which prioritised Stories will be covered in the next workshop. It may also be to select some themes amongst the prioritised Stories to help the flow of the conversation. These initial discussions while preparing for the workshop may also involve the Product Manager, User Experience Designer, and Visual Designer to both understand what they are thinking, but to prepare them for the workshop. The Business Analyst may also choose to do some preliminary analysis prior to the workshop. This may go to the extent of writing/drawing some scenarios to take the team through, or have some questions ready to ask the team if required. This decision is probably up to your own personal preference.
I’m all prepared now… what do I do?
There are a number of different approaches to running a Story Card workshop. I’ll be taking you through my preferred approach and I have received feedback from my colleagues that it works really well. I have adopted this approach from Andrew Thorpe, who introduced this technique to me earlier this year.
Taking the prioritised Stories into the workshop the plan is to go through one Story at a time in detail. I normally stick the Story Card on a white board and draw 3 columns on the board – In, Out, and Questions (?). These columns are to write notes about what is In scope for this Story, what is Out of scope, and any Questions to follow up after the workshop.
The In scope column will normally be filled with lots of information about what needs to be done for the Story. What is the outcome being achieved by this Story? What should the User Interface include? Do we need any validation? All of these requirements are elicited from your cross-functional team.
The Out of scope column will include a number of bits of information. What doesn’t need to be done for this Story? What is going to be covered by another Story in our Backlog? The Questions column is used either because we don’t have the answer in the workshop or the discussion has gone on for too long and we need to park it. Notes are captured in short form and in the context of the Story and workshop. If I need to move an item between columns I will sometimes just use an arrow to indicate this.
This approach is repeated for each Story that will be covered in the Story Card workshop. At the end of the workshop a photo is taken of all of the outcomes. By running the workshop in this manner, I find that the team can cover lots of detail because we’re focused on one specific task – identifying the requirements for each Story. I also find that the team leaves the room with a shared understand of what needs to be developed.
What happens now? I’ve run my Story Card workshop
Using the discussions, notes, and photos from the Story Card workshop there are a few items that need to be organised:
- the questions that were noted should be answered;
- the requirements will be documented as Acceptance Criteria for each Story;
- wireframes and visual designs may be developed or updated to take on points from the discussions.
From there the Story will be picked up by the team to develop either in the current or the next Iteration.
So there you have it. I have hopefully explained what a Story Card workshop is all about, how to run this workshop, and what is the benefit of them. To sum up, the Story Card workshop is ideally run each Iteration to ensure the team continues to talk about what work is coming up, and to discuss the details of each Story. The outcome will be that the team knows what needs to be worked on and there is an agreement of what the requirements are for each Story.
