Background
What is the role of the Product Owner during User Story estimation? In Scrum, the Product Owner pulls from her backlog of User Stories, the top stories she wants to accomplish over the next several iterations. The Product Owner reads the story out loud then starts a conversation about what she expects from the story. If she wishes and/or the team desires it, she can pass the story around for the team to read. The team can ask questions related to the User Story; after which estimating begins. For this discussion, I am referencing Story Points (as opposed to t-shirt sizes, etc.) as the estimation method. All of this happens within a few minutes, but can take a little longer if your team is new to the technique. Traditionally, the Product Owner has been kept out of the estimation process. After all, the argument has been made (and in my experience rightfully so in many cases), that the ones doing the work should be the only ones doing the estimating.
Something unexpected
At one of my recent clients, I had the good fortune of being given a Scrum project that was already in flight and responsible for building out a widely used corporate application. The team had already used Story Points to estimate User Stories in previous iterations. However, one thing that was radically different then what I had experienced before, the Product Owner participated in the estimating process. Another thing that was radically different from what I had learned previously, it actually worked for the team!
I have been involved with organizational change for several years now and one thing I have learned is that it is very important to know when to put your foot on the gas, when to take your foot off the gas (i.e. coast), and when to apply the brakes. In this instance, I decided to take my foot off the gas to see how the team progressed. I was amazed at what I saw.
The Product Owner:
- Was more actively engaged
- Took greater ownership for the User Stories that were in the backlog and put into the Sprint
- Had a greater understanding for the work required to implement the User Story
- Enjoyed a shared sense of camaraderie with the development team
- Felt like he had a voice that was heard
The Development team:
- Appreciated that the Product Owner was taking a stake in the process
- Appreciated that the Product Owner listened to their points
- Had a greater understanding of the work required on the part of the Product Owner to implement the story ( In many instances during a given Sprint the Product Owner needed to follow up with other people in the business to get finer grained details on how the story should be implemented)
My Thoughts on Why it Worked
In my experience, I found this situation to be unique and I think there were a few factors that led to the success of this estimating approach.
First, the development team had a track record of delivering on commitments within the Sprint. Based on that experience, the product owner had built up enough trust with the development team that he put great weight on their estimates. Therefore, he often (in most cases) yielded his estimate to that of the team’s.
Second, the Product Owner had a consulting background which I believe contributed to his flexibility and openness. From my experience as a consultant, I have found that in many cases consultant’s have a greater ability to listen, learn, and adapt to a given environment then their client’s employees. Because a consultant’s work is project based and they work with multiple organizations (and cultures and personalities) over the course of their careers, consultants are often times more in tune with the variability that exists within the organizations in which they work. I believe this experience helped our Product Owner align estimates more closely with the team.
Third, the development team was extremely good at articulating what was needed to develop the User Story in terms the Product Owner could understand. I found this trait to be different from most of the development teams I’ve worked with in the past. Usually, the development team is more comfortable talking in technical terms (i.e. stored procedures, XML serialization, etc) when discussing the complexity of the story. Explaining things at a level the Product Owner could understand helped add clarity on what it would take to develop the User Story.
Fourth, the development team was assertive with their points of view. Again, this is something that I found in contrast with most of the development teams I’ve worked with in the past. Often what I experience in large organizations is that the Product Owner (or anyone from the business for that matter) is in a position of strength and the development team is unlikely to challenge the Product Owner. Obviously, in these situations, it is not a good idea to have the Product Owner estimating with the team. However, this was not the case in this situation. If the development team held up a number that was higher than the Product Owner’s, they stood their ground on why they felt it should be the higher number. Any disputes were worked out by the TEAM (inclusive of the Product Owner).
We estimated like this for the duration of the project, until its successful conclusion. I even complemented the team on their estimating techniques and skills (they laughed!) at our last retrospective. Have you found yourself in a similar situation or have a differing view point on this? If so, I’d like to hear!
Recent Comments