A Product Owner’s journey from traditional to Agile

I start this article with a statement “Agile development is being driven by the product”. This is really true but only when product has key agile knowledge. If not, it may lead to unsuccessful delivery of product or delivering a wrong product at wrong time which will impact the ROI.

What is Value? Value is delivering a capability to the customer through which the customer can attain a tangible or intangible benefit. Product owner role is very key and important and in delivering the “Value” to the customer.

The journey: I recently worked on a project in which almost all in the Scrum team are new. Especially the product owners worked in traditional project delivery model and they used to derive pages of specification document which captures the functional, non-functional requirements in the form of sections and paragraphs. One fine day the management decided that the way forward is agile so the project has to be delivered using agile. Then the struggle started….Why? Someone decided that we are going to use VersionOne for the agile project management and the requirements have to be written in the form of “User stories” and tracked/prioritized through the Version One tool. The product owners did not have any idea on the tool as well as prioritization techniques.

So what happened? They first started writing the requirements in a word document with beautiful paragraphs with section numbers. Then they jumped on to the VersionOne tool and started writing stories using the format “AS A <User role>, I WANT TO <Some action>, SO THAT <some benefit”. Till here it is fine. The actual problem surfaced was, they started attaching the sections from the spec document to the user story. This has killed the definition of user story and the stories were not satisfying the “INVEST” principles. More over, this approach has led to many issues as described below:

1. It was very difficult to identify “what is the value” of the story because it is not simple but has a bulk section from spec document attached to it….
2. It is not possible to prioritize the stories because the “Value” is not in the story by in the attached spec document’s sections. The section is bigger than Epics 
3. Product owners starting updating the attached sections in the spec document without any change to the user story. This has impacted the estimation
4. Sizing (estimation) was very difficult as the story is not properly sized
5. Arriving at Definition of Done was very difficult
6. There was no proper acceptance criteria defined due the ambiguity in the stories
and many more practical issues….

What did I do?

I have quickly assessed the situation and discussed with the senior management and the product owners and got their buy in for my plan of action. With their support, I have executed the below approach:

1. First step, there was a quick half day session provided to the product owners to explain:
a. What is their role?
b. What are their responsibilities?
c. How they need to work closely with the development team and Scrum Master?
d. What is a user story, Epic, Theme and the relationship?
e. What is a product backlog and how to create and manage it simply?

2. I arranged another half day workshop for them to let them practically write the user stories and decouple the requirements from the spec document. I used post-it, white board, different colors of markers to make the session interactive and lively. During the session I also explained them the prioritization techniques MoSCoW, Kano model and theme scoring. They finally selected the MoSCoW for prioritization. I also had the development team in this meeting and explained them how to conduct sprint planning, review and retrospective ceremonies. I also covered how to track the “remaining work” using burndown charts. Most importantly how to work with product owners in order to achieve the “maximum value” delivered at the end of the sprint.

3. Based on the above knowledge and hands on experience, the product owners and the dev team felt very excited and wanted to apply the same to the actual project. This has made my job easy. I asked them to come up with their most high priority features/requirements in terms of user stories and helped them to make those stories satisfy “INVEST” principle.

4. The final step was to make the product owner and the dev team and Scrum master work very closely to define our first release for the selected stories. The sprint planning was done next and the team took 3 sprints to come to a rhythm to deliver the velocity that is expected.

All is well that ends well, after the above exercise, everyone in the team has got good insights to the Scrum and their confidence levels increased significantly. Now they started talking in Scrum language using release, sprint, velocity, high performance team, burndown, impediments, etc …

I end this article with a salute to the Scrum values “Openness, Courage, Respect, Focus, Commitment”. These are like mantras to the Scrum teams to digest in the daily work so that they can become truly “high performance” and “self organized” teams….

If you need more details on this training or you’d like to attend the training, please contact us on +91 99499 94949 or email us at contact@learnovative.com