Many of you probably agree with me if I say that a successful Sprint is the result of a good planning session. But how do you ensure a good planning session? I have experienced countless sessions that didn’t have the right feel to it. When this happens it feels like the session takes forever and everyone involved gets drained of energy.
To make sure the team is well prepared for the planning session, I would like to highlight the User Story Lifecycle. This covers the different stages a User Story should go through in order to produce any business value.
User Story Lifecycle
In the image below you can see a simplified process chain of the User Story Lifecycle.
If we assume that we have a backlog and that it contains a mix of User Stories and Epics. In order to be able to deliver any value to the end-user, a story needs to go through the following steps: Prioritization, User Story Creation/Workshop, Backlog Grooming, Sprint Planning, and Implementation. I am mentioning here that all stories need to go through the whole chain in order to be deliverable. You may wonder if this is really true. Well, for all stories, the different stages require a different amount of work. Some stories are so clear cut that they can pretty much jump straight to implementation. But along the way it will have passed all the filters for each stage, you might just have missed that fact since the work was so small. Whereas other stories, perhaps, require more than one lap through this chain.
During this stage, the priority of the upcoming work is decided. So for an individual story, this is where it gets weighted against all other stories in the backlog.
As input at this stage we have the backlog, which contains Epics and User Stories. We also have the developers’ feedback, thoughts and opinions regarding the product. Some kind of gathered data to help us understand user behavior within our product i.e. Google Analytics. We also need to consider external dependencies when deciding upon priority. Are there any deadlines in other projects that are dependent on us?
We won’t go in to the details of what happens during this session, but instead focus on what we want to see as a result of it.
One obvious output is the re-ordering of the backlog items to reflect the priority. This can in term be translated as the direction or main focus of the product at this point in time. The direction can maybe be seen as a short-term vision, but I prefer the term focus since it implies some sort of time aspect. A product vision should almost not be achievable, while focus helps us direct our efforts to something we see as important right now. Another thing that should be an outcome of this is an assumption about user behavior in regards to the end-user value for each Epic/Story. This is to help us understand what it is we want to measure. How do we validate our thesis?
The last thing we need from this stage is some sort of motivation to why we have chosen the priority and direction. A simple “because reasons” won’t fly with highly skilled and intelligent engineers. Make sure the motivation is grounded in reality. For example; this feature is important because we think it will help increase our user base with X% within the first quarter after its release, which is in line with our global target for the next quarter. Or, this feature is important because we have another product that is dependent on a first release in order for them to continue development.
A workshop aimed at creating User Stories can be done in so many ways. I won’t cover this topic in detail, instead I will focus on some things that are, in my experience, easy to overlook.
In order to have a fruitful story creation session, at the very least you need a set of prioritized Epics to start with. You can also pull in high priority stories that might need some work or that simply didn’t manage to get completed during the last lap of the cycle.
When the session is done there should be a number of stories created that each has its own information attached to them. One piece of information that I would truly like to highlight is the Definition of Done. This is the contract between the Product Owner and the development team. When this story is delivered; the DoD details the expected behavior. Everyone needs to agree on this and understand it.
Another thing to highlight is the MVPe, the Minimum Viable Product experiment that will allow us to validate our assumption about end-user value. Is there a tiny amount of work we can do and deliver to the end-user, in order for us to learn more before we spend a lot of effort completing this feature? This part is in my experience often overlooked.
Yet another thing, closely related to the MVPe, is the MVP itself. This is the Minimum Viable Product release that we believe will fulfill the market need for the product. This part is something that should be created iterative, and will benefit greatly from the MVPe in the first iteration. While both the MVPe and the MVP should be as small as possible. The MVPe needs to be big enough to be able to validate our assumptions and the MVP needs be ready enough to fulfill the user need without dragging down the rest of the product.
We mentioned the DoD above, but we are not done with it. One cannot stress enough the importance of DoD. As said before, this is the contract between the PO and the development team. If we do not have this in place well before implementation, we simply cannot manage the expectations of the story.
If the developers haven’t been a part of the process so far, this is where they get involved. The purpose of the Backlog Grooming is mainly to get the stories ready for implementation. We need to get the conversations going among the developers in order to surface any technical obstacles or dependencies towards other parties. We also want some kind of indication towards the cost of implementing something that can be weighed against the benefit of doing it.
Going in to the grooming session we want to bring us a number of high priority stories that is intended to be implemented soon. This is simply because we want to be working on relevant things and not speculate too much about what the future might hold. The stories that we bring up during the grooming should fulfill the exit criteria we have for the User Story Workshop, there should be a Definition of Done, the smallest possible experiment that can be performed to validate any assumptions made as well as the minimum releasable functionality to fulfill the user need.
During the session it is important to ask questions that will steer the discussions towards technical details that will surface potential issues as well as dependencies. Another reason to encourage technical discussions here is to get the architectural discussions going. Rarely is the first idea the best idea. There is also the aspect of the brain’s ability to process information subconsciously. What this means is that the brain will continue to work on something in the background, without you having to think about it actively. If you have ever tried to solve a complex problem but got to a point where you got stuck, you might have experienced somewhat of an epiphany at a later time when you all of a sudden get an idea that will take you passed an obstacle. This is an example of the brain processing the information in the background. I have several times been involved with teams that need to redesign whole solutions in the middle of the Sprint because some aspect of the design did not work at all. This can be avoided to a large extent if you just make sure to give the brain some time to work on the problem passively, before you tackle it actively.
The outcome from the grooming should be a more refined User Story, it should be broken apart where it deemed useful, it should be estimated (#noestimates?) and the DoD should be revisited to make sure it can be used to manage expectations. The way forward should also be clear at this point. Is it more suitable to implement the MVPe and measure something before we tackle a bigger part of the story, or will the complete story bring so much value to the end-user that we can start with that right away?
Everyone who has heard about Scrum has heard about Sprint Planning. This is where the team sits down and plans their coming work period. The goal here is that the planning should not take more than 30 min/week in the Sprint.
I believe that many people out there struggle to get the feeling of a successful planning session. It often feels like it’s going on forever and is a real energy drainer. We all like to feel productive and efficient when we do things. By making sure we have done all the necessary work before the planning session, and only bring in well-groomed and discussed User Stories, we set ourselves up for success. During the planning we quickly revisit all the previous steps for a story; we make sure that the information we have gathered and documented is still relevant. If any new information has emerged we need to discuss it and take it into consideration.
The outcome of the planning session is a committed scope by the development team. This is to be seen as “will most likely be delivered”. Any high priority stories that didn’t fit in to a Sprint should be labeled as “next in line” and go through the cycle once more.
During implementation we slowly start to get feedback regarding how well we managed to prepare. Do a lot of new tasks appear on the board? Do some tasks take longer than expected? There is not much to do about these kind of things during an ongoing Sprint except to handle it in the best possible way to ensure the Sprint goal is fulfilled. It is however very valuable input to the next planning session.
At the end of the day, it is what you manage to finish in the Sprint that actually matters. To be able to finish things, you need to have had a conversation around the functionality and design so everyone knows what is involved. This process is about fueling that conversation between the team and PO.