I start this article with a statement "Agile development is being driven by the product." This is really true, but only when the product has key Agile knowledge. If not, it may lead to unsuccessful delivery of the product or to 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. The product owner role is key in delivering the "value" to the customer.
I recently worked on a project in which almost everyone in the Scrum team was new. The product owners in particular had worked in traditional project delivery models, and they used to derive pages of specification documents that captured the functional and nonfunctional requirements in the form of sections and paragraphs.
Then one fine day, management decided that the way forward should be Agile.
The struggle began. Why?
Someone decided that we were going to use VersionOne for the Agile project management, and the requirements had to be written in the form of user stories and tracked and prioritized through the VersionOne tool. The product owners did not have any idea how to use the tool or any prioritization techniques.
They first started writing the requirements in a Word document, in beautiful paragraphs with section numbers. Then they jumped onto the VersionOne tool and started writing stories using the format "As a <user role>, I want to <some action>, so that <some benefit>." So far, so good. The actual problem surfaced when they started attaching the sections from the spec document to the user story. This killed the definition of the user story; the stories did not satisfy "INVEST" principles. More over, this approach led to many issues, as described below:
It was difficult to identify "what is the value" of the story, because it was not simple but had a bulk section from the spec document attached to it.
It was not possible to prioritize the stories, because the "value" was not in the story but in the attached spec document's sections -- which were bigger than epics.
Product owners started updating the attached sections in the spec document without any change to the user story, impacting estimation.
Estimation was difficult as the story was not properly sized
Arriving at a Definition of Done was very difficult.
There was no properly defined acceptance criteria, due the ambiguity in the story.
Those were just a few of the practical issues.
What did I do?
As the Scrum coach on this project, I assessed the situation, discussed it with senior management and the product owners, and got their buy-in for my plan of action. With their support, I executed the approach outlined here:
As a first step, there was a quick half-day session for the product owners to answer several questions.
What is their role?
What are their responsibilities?
How closely do they need to work with the development team and ScrumMaster?
What are the user story, epic, theme, and their interrelationships?
What is a product backlog and how does one create and manage it simply?
2. I arranged another half-day workshop for them to write the user stories and decouple the requirements from the spec document. I used post-its, a whiteboard, and different colored markers to make the session interactive and lively. During the session I also explained the prioritization techniques MoSCoW, the Kano model, and theme scoring. They ultimately selected the MoSCoW for prioritization. I also had the development team at this meeting and explained to them how to conduct sprint planning, review, and retrospective ceremonies. I also covered how to track the "remaining work" using burn-down charts. Most important, we discussed how to work with product owners in order to achieve the "maximum value" by the end of the sprint.
4. The final step was to make the product owner, development team, and ScrumMaster work closely together to define the first release for the selected stories. The sprint planning was done next, and the team took three sprints to come to a rhythm that helped them deliver at the expected velocity.
All's well that ends well. After these exercises, everyone in the team had good insights into Scrum, and their confidence levels increased significantly. They started talking in Scrum language, using such terms as release, sprint, velocity, high-performance team, burn-down, impediments, and so on.
I'll end this article with a salute to the Scrum values of "Openness, Courage, Respect, Focus, Commitment." These are like mantras to the Scrum teams in their daily work, so they can become true high-performance and self-organized teams.
I'm interested in your feedback on this article. Thank you.