Skip to main content

Agile Methodology for product owner


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.[1] 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.

Popular posts from this blog

The power of visual storytelling

I recently came across this wonderful commercial of Canadian Tire "Wheels"






This ad was a slam dunk for a very basic reason - Within 60 seconds, message was delivered and hearts were touched, thanks to powerful storytelling

The ad starts with a kid in wheelchair, looking wistfully at the group of boys playing basketball.

What's Next?

Next day the same group of boys are playing basketball, but in a special way 😊

Pause reading. Go watch this Ad - Canadian Tire "Wheels"

Lessons - 

Everybody's Inclusion will strengthen the nation
Hardships can be ignored or can be celebrated together

All it took is just a minute to deliver this strong message

Next time whenever we will see Wheelchair or Basketball, we surely going to remember this Ad

This is the power of Visual Storytelling

Until next time 😃



Left brain - Right brain - No brain

In one of my previous post I mentioned how you can alter your perspective by teaching your left side of the brain - responsible for logic, to perceive things differently

Continuing on same thoughts - Left side vs. Right side of the brain, today I'll extend it to Verbal vs. Visual side

Left side, which is responsible for the analytical, logical approach, looks for verbal clues.

Tip - If you want to be a good speaker, keep nourishing your left side of the brain by practicing and analyzing good speeches

So every time you hear a speech or presentation, left side of the brain start working by synthesizing that information. Breaking sentences into chunks, looks into existing vocabulary to understand the concept

While all this time what is our right side of the brain doing?
Nothing?

Well it is trying to form some visual picture of the same presentation

Remember those good old days when our parents tell the story?

Once upon a time, there was a king named Paul....

Left side of the brain wi…

How to Sell Anything?

Everyone is a salesman. We have been selling physical products or ideas or emotions since the inception of the time. Still most of us, including me, are pathetic in the art of selling. 
This post is about how to master this art - in three simple steps
Ethos - Pathos - Lagos (Formula given by Aristotle)
Ethos – Establish yourself by showcasing a prolific profile of yours - maybe your past accolades, superior track record, high end connections, exceptional knowledge, blabbering data etc. 
Pathos - Next step is to invoke emotions. We humans have exceptional capability of rationale but emotions cloud this capability. So try to invoke emotions of happiness, loss, urgency, ego etc.