We have just finished with the Penn State University Project. This project was a way for me to evaluate the reverse sourcing phenomena and to make a difference to our education system by playing a demanding customer’s role for a University project. Overall I had a great experience doing this and the students really enjoyed working on this project. (I owe a separate blog to talk about the overall project, now that it is over). In this blog, I want to highlight something that I always felt about user stories but was not clearly able to articulate.
The Mystery of Shrinking Stories:
Over the last 5+ years of my experience with User Stories, I’ve seen people constantly trying to reduce the scope (size) of the user stories. (Jeff Patton has a really interesting blog about the same). Seeing this trend I’ve been frustrated a lot of time when my customer or team members don’t understand what is happening.
The problem was the stories were too granular that it was easy to miss the big picture.
Functional Areas :
To avoid this problem we started grouping the stories into functional areas. The Product Owner would identify the highest priority functional area and we used that functional area to identify our iteration/sprint stories. The developer would come up with a list of stories and tasks that fit under that functional area. (Mostly this would be done before the planning meeting). In the planning meeting we would have a collaborative session with the Product Owner to decide what stories need to go into the iteration/scrum based on the estimates. But we still had a big estimation session and then we would identify a list of stories. This clearly simplified our planning meeting, but
- The team members still did not have 100% clarity during the iteration/sprint on why certain stories made it and some did not.
- Both sides felt like there was a compromise in terms of the identifyed stories. The Product Owner might want some story but the developers would say its not possible because the estimate is high on it. The Developers might want to work on some story because it makes sense from a technical point of view, but the Product Owner did not prioritize that story.
- Also another problem we ran into was there were a lot of times when we wanted to pick stories from different functional areas. But in this approach we could pick up stories only from one functional area.
Using Themes instead of Functional Areas
We used different approaches to identify Themes.
- First we started off with identifying a list of high priority stories and then tried to put a theme around it. This clearly did not work as well.
- Some times we tried to identify a list of high priority functional stories and use a theme for the technical stories. This worked well when the technical debt was really high. For Example, Refactoring is a theme for this iteration/sprint.
- Finally we asked the customer to identify a theme and the developers would then identify stories based on the theme. This was very similar to the functional areas except that now we could identify stories from different areas.
Again we had similar issues with previous approach.
Each Iteration/Sprint has a clear Goal
Finally we tried having a goal per iteration/sprint. The Product Owner would communicate the goal to the team; the theme would discuss about the goal with the PO and get their clarifications. After which the developers would come up with a list of stories that will help them achieve that goal. Sometimes they might only be able to achieve part of the goal, and then the goal will be updated accordingly.
This gave the business folks to clearly communicate what they wanted to see at the end of the iteration and also that fits into our release goal (each release had a clear goal, but before this we did not have a goal per iteration/sprint). For the developers this meant they could thin slice the stories accordingly to fit into the iterations. Suddenly developers moved from an estimation mindset to a budgeting mindset. Also from the PO’s perspective the story is really the goal, which is fairly high-level and the developers used user stories as tasks to keep track of progress and to split work amongst them. I was never a fan of tasks under the stories and this helped us get rid of them. Technically user stories (not really give by the user, written by the development team from user’s perspective) became our tasks and the goal became our user stories. This way we were able to make our stories quite large in scope (really, its one story per iteration/sprint). There is a similar concept in Scrum. They talk about Goals for a sprint, but there are multiple goals per sprint. In our case we had only one goal per sprint and we had stories under that.
What we did on the Penn State Project:
We started off with me (Customer or Product Owner) explaining them the overall vision of the project. So that, all of us has the same mental model. We used a mindmap for this. Next, I started of setting a goal for the iteration and also giving them a list of high priority stories (since they were new to the whole concept of stories). After a few iterations, I just gave them goals, asked them to email me the stories the next day and then in our bi-weekly demos, they would demonstrate each story and I would get to rate if they fulfilled the goal or not.
Some sample Goals are:
- Have at least one conference up and running
- Build versioning into the system ( This meant they had to add version each page, each artifact under the page, version templates, version the whole conference, there could be multiple conference under one site, so version all of them)
- Add template support (This means layout templates, Style sheet, include template, etc)
This has been my experience of moving away from Granular User Stories to Goals. I would love to hear your experience.