The elephant….a rather huge animal, isn’t? Is it possible to eat the whole elephant at one time? What do you think? Some of my teams really want to do this and, no doubt, they fail. The teams neglect to decompose large User Stories/Tasks too often. This happens because of many various reasons: they do not feel the value of it, it is too difficult, and etc.
I have explained my teams that a large User Story or Task is difficult to evaluate, because it is not clear enough, not transparent, and there are a lot of questions that are to be answered and this kind of task will never be completed in one Sprint. As a result I decided to prepare a workshop on the basics of User Stories Decomposition.
I have already held my workshop several times in different teams: both product and business ones. The number of participants varied from 7 to 30. And each time the participants ask a lot of questions, which were the same in general, but sometimes completely unexpected topics arose. But when there are many questions – I find to be great, as it means that the participants are motivated, they strive to comprehend this complex topic. Do you agree?
When I started thinking about the design of the workshop, I decided to start from the very beginning: where User Stories come from and what they are. That is why after opening the workshop (the agenda, timing, goal, value and expected results), I ask the participants to share what difficulties they face in decomposition, and then I ask the question: what is a User Story? How does it appear in our Product Backlog?
Some of the participants will definitely tell you something, but this is not enough. So I smoothly move on to the User Story Map and how the Product Backlog is built. I show the stages of formation, I ask questions for understanding. During this theoretical stage it is very important to keep the attention of the participants. Therefore, I try to attract their attention with questions: how about you? what do you think will be the next? type a plus / minus in the chat, is it clear or not, and so on. Thus, the participants are not distracted and continue to dive into the topic.
After the User Story Map, I summarize what we learned from the previous module and move on to defining a User Story itself and the criteria for a well-decomposed story – INVEST. I use the same tactics of involving the participants into the discussion.
When we learned what a User Story is, I begin to show the strong positive influence of decomposition, why it is needed to be done and ask the participants to comment on whether they agree or not, why, whether they understand or not. I’m trying to correlate the difficulties that they recorded earlier (at the beginning of workshop) with what I’m telling them now.
And so, slowly, step by step, logically we begin to discuss open and closed stories, as well as why closed stories are better. I ask questions and lead the participants to the fact that they themselves answer these questions. And at this moment we take a break for 10-15 minutes, announcing the second part of the workshop, where we will get acquainted with the other decomposition methods and practice.
After the break, we discuss the simplest SPIDR model and then I suggest doing the first exercise. It is aimed at getting acquainted with other methods of decomposition.
The methods are in the special frame of the board. The first exercise consists of two parts: 1) choose one or two of the proposed methods (the quantity depends on the number of participants – it is important to cover all methods) and sign them with your name. 2) in the session rooms (I prefer to divide by three people) it is necessary to read the chosen methods and discuss them. If there are questions, the participants can ask them upon their return to the common room. If questions are asked, I try to address them to all participants so that they can answer themselves; if they are mistaken, then I correct them.
After that, I suggest doing the second exercise. I prepare many frames at once, put all the important theoretical material and the tasks there so that the participants feel comfortable and do not have to waste time looking for what they need to do and what to use. Participants should be divided into session rooms. The task is as follows: each frame has a pre-prepared User Story. It is necessary to choose ways to decompose it at least into two US. If more than one option seems to fit, then only one should be selected. Participants should be sure to choose one from the group, who will then tell in the common room which method they’ve chosen and the result. The US is one and the same in all rooms (frames). Upon returning to the common room, the participants demonstrate their results. Here I act according to the situation and taking into account the number of participants: if there are few participants and there is time, then everyone tells. If not, then only willing ones. If there are no people interested, then I take odd rooms and ask them to tell.
Well, after that goes the third exercise. It is also to be done in session rooms, preferably in the same ones that were previously. The third exercise is that the participants have to choose one US from their own Product Backlogs that they cannot decompose, show each other and choose only one. And then they should decompose it into at least two and check if US meets INVEST criteria. Just like in the second exercise, they need to choose one representative who will tell the result. Others actively participate and comment.
At the end of the workshop I explain what to read and ask the participants to leave their feedback and comments. And the next day I send out all the materials and a link to the board where they worked.
I usually held this workshop on Friday morning. Every time on Saturday I receive notifications in the email that there are activities on the board. I think that this is a sure sign that the participants are interested and they have learned something useful for themselves.
If you have questions or want to share your experience, write to me in Telegram or LinkedIn. I would be very happy to chat.
