We know the roles: product owner, scrum master, and the team. The team is consisted of developers, DBA’s, business analysts, testers…anyone required to get the product completed (while being mindful of team size – i.e. the 7 plus or minus 2 rule). A good agile process promotes cross-functional teams, and transcends traditional role responsibilities. The team should be empowered to get it done, regardless of traditional role boundaries, acting as business analyst, DBA, developer, tester, etc. as needed.
In transitioning organizations from the traditional waterfall process to an agile process (Scrum, Kanban, etc.), one point of pain lies in requirements gathering. In waterfall, the whole group gets together and hashes out all of the requirements prior to starting development. Even if a member does not contribute throughout the meetings, they are still there, just in case. This “just in case” mindset causes a lot of waste in time and productivity. A business analyst or product manager attempts to hash out the entire product, developers spend time providing input, stakeholders are consulted, etc. Then a few weeks/months down the road things change, and its impact can be significant.
This is why, in agile, a SINGLE (emphasis on single) product owner provides the requirements from a USER (emphasis on user) perspective, and defines the story as needed – “As a user, I want to log in securely.” This is different from creating a story with ultimate definition, full of technical details, on how this login will take place, as may be the case in a waterfall process. What if a few weeks/months down the road the stakeholders decide they want Facebook login, or some kind of SSO? By keeping the definition at the user level, it leaves room for change. When it’s time for a team member to move that story into the iteration, or “in progress”, if further definition is required they can consult the product owner, who should be on top of any new requests/requirements. The technical details are left to the team member, and the story is completed within a short iteration, just in time. There was no wasted time fully detailing out the story, and then having to do it over again when/if things change.
Remember to avoid the desire to define things perfectly from the start. Product development is an iterative process, and with the tools available today that dramatically increase development time we have the opportunity to generate feedback in a matter of days/weeks rather than months/years. Keep your iterations short (I like 2 weeks), demo what you’ve completed in that iteration and measure the response, and learn how you can stay on target for future iterations. Complete this build, measure, learn cycle throughout the product life-cycle to eliminate waste and provide the most relevant product possible.
A short note on single product owners: When defining requirements, and providing the ultimate vision, a single product owner is important to remove ambiguity and conflicts. The product owner becomes the final say, and the only say as far as the product team and scrum master is concerned. When the stakeholders change their mind, the product owner gathers new requirements (from a user perspective), and updates the backlog as needed.
Have questions on agile, Scrum, Kanban, lean thinking, or any variety of new terms in product development? Please contact me here, via my website.