Product owner, generally has a vision about the product. This vision can be as simple as the problem it is going to solve, to as granular as how it is going to look like, what are the target markets etc.
The product owner is day-in-day-out fascinated with this idea
In this post I am going to talk about this Product owner, let’s call him Adam, and what Agile Methodology means to him
Before moving to the story of Adam, lets see Wikipedia definition of Agile -
"Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change"
Now back to the daily life of Adam
- Besides Adam, there are stakeholders – those who are going to use this product and spread the good / bad word about it
- Adam pens down his thoughts in form of these stakeholders or user personas. These penned down stories are called User Stories (a pretty obvious name eh?)
- To build these ideas into system, we have developers – group of people using diversified technical skills so carry out Adam’s vision of building amazing product for stakeholders
- Being an Agile team, they release the product in multiple iterations
Let’s assume we have a 10-member team with capacity of developing 1 story (for simplicity sake task) per person per week. Thus capacity / output of our team is 10 stories per week.
Now by the time our dev team carve out Adam’s vision, our stakeholder might come up with dozen different requirements. These requirements will again be added to dev team
It’s easy to vision that input stories to dev team will soon outnumber the output, resulting in pretty unhappy dev team
Solution? - Follow an Agile methodology, the two common approaches under it-
Scrum = Basis on past behavior, dev team can state weekly task limit (10 in our example) thus we can fix the input limit to 10 weekly stories
Kanban = For each story output, we can have corresponding input (thus making sure each developer is always occupied 😉)
We have tons of stories get produced at the input, called Product Backlog – again maintained by Adam
Q - Maintaining additional input stories will leave plethora of backlog. How to deal with it?
A - Say No to these extra stories (at least to some of them)
Q - How can we identify those stories which does not need our attention?
A - Estimate value and size of each story
Size = amount of dev efforts going into implementing this task
Value = Greater Revenue / Extra customer / Additional engagement
This exercise Is called Backlog grooving – Prioritization, Estimation, writing stories, setting acceptance criteria
Now while establishing this vision, there can be multiple risks -
- Social Risk
- Business Risk
- Technical Risk
- Estimation Risk
Trade Offs to consider –
- Customer Value vs. Knowledge Value (Time)
- Urgent bug fix vs. Cool new feature
- Reactive Work vs. Proactive work
- Building Right thing vs. Building things right vs. Building product fast
As you guessed it correctly, Adam has to think about it and basis which feed stories to Agile Dev team to help them carry his idea.