Tuesday, May 22, 2018

The best Product Owner

Product Owner's Qualities and Characteristics:

1) Engaged in the product life cycle: The best PO is engaged in the entire product development life cycle. A dis-engaged PO finds him/herself outside of the process quickly. An engaged PO is a natural leader. S/he finds himself leading a team through his decisions and makes it apparent to the team that s/he is committed to not only the process, but the final product as well.

2) Always Available: The best PO is available to the team, but with a reason. It is important to co-locate the PO within the team so they have zero walls to climb in order to receive feedback and potentially daily guidance. The availability can come at a cost, with an immature team who is lacking the accountability and responsibility of building the needed project. Be tactful here and give a healthy balance between availability and spoon-feeding a development team. Sometimes empowering the team to help themselves can create a partnership between team and PO that improves productivity!

3) Informed about the product – The best PO know the product inside and out. Subject matter experts on not only the product but also the market will be prepared for giving updated feedback and guidance to a development team. Understanding beyond the product can help here as well, but core to the PO role is his/her ability to intimately know and understand the product they are helping a development team to build.

4) Empowered through humility – The best PO is the authority for product. S/he has been given the official right to make executive calls on product direction and feature-set. S/he has been granted this permission and power through her/his ability to lead with humility. They show their humility by making the right choices, and correcting poor product choices through due diligence and research. They intimately know their power comes at a price, because in the end, their power of decision can make a company grow, or fall into obscurity with poor product development.

5) Prepared and responsible – The best PO is always prepared. S/he comes to the ceremonial meetings prepared and ready to make decisions and take action. Preparation is the key here. S/he gains trust from the development team because the team knows that the PO is always prepared and responsible for the outcome of the product specifications and features. Development teams like go to the nearest “prepared” individual for better guidance and direction if the “official” PO isn’t giving justice to her/his role.

6) Knowledgeable about history – The best PO has spent enough time on the product in the company. S/he has seen the ups and downs of the product life-cycles, and understand how the customer values the product. S/he must have a firm foundation of knowledge to pull from when decisions need to be made. S/he knows the historical path of poor product development and poor product launches. And sometimes, s/he was the reason. But s/he learned and used that experience to create even better products and services.

7) Communicative in nature – The best PO is natural communicator. S/he knows how to leverage communication to get their point across so they can give undiluted guidance and direction to a development team. S/he knows how to reach not only the customer, but knows how to speak the development language. Developers respect, trust, and look forward to working with a communicative PO. S/he respect the PO because the PO knows how to speak on the level of the developer and may even, know how to code and develop himself!

8) Collaborative by choice – The best PO is team player. S/he values the team and collaborates effectively with the team in regards to providing timely and valuable feedback. Collaboration is a choice. It takes time, it takes effort, and it takes commitment. The worst PO says “Here is what I want and get it done by tomorrow”. The best PO says “Here is what we can do for our customer and let’s see how we can build it in the best possible way!”

9) Agile in all things – The best PO is flexible, in all things. S/he understands that software development is not a hardened process, but fluid, all the time. S/he works collaboratively with the team when changes must be made. S/he doesn’t get angry when previously unknown impediments and constraints come up. S/he is flexible because s/he is prepared with - a prioritized backlog, daily communication with the teams, intense research on the product and market. And that’s the true “Agile”.

Product Owner's Roles and Responsibilities:
1) The role needs active participation in all phases of project life cycle in Agile Process.
2) Needs to actively work with Product Management team to gather the software requirements and convert those in the form of user stories – Acceptance Criteria.
3) Draft acceptance criteria for each story.
4) Create screen mock ups for new screens. Work on user experience improvement ideas and get those approved by management.
5) Analyze database changes needed for each story.
6) Perform user acceptance testing. Take accountability of accepting the work done by the team.
7) Consistently work on improving one’s domain knowledge.
8) Prepare documentation for changes in each user story.
9) Participate in retrospectives with valuable inputs to the team.
10) The role needs to make sure that team understands the stories without any communication gap between the team and Product Manager.
11) Very active participation in business/functional requirement gathering, analysis and understanding, clarification sessions.
12) Active participation in design of application user interface, flow diagrams and integration activities with various other applications.
13) Mentor junior and new resources in the team from functionality standpoint.
14) This role needs candidate on call or meetings sometimes in extended hours.
15) This role might need some visits (on need basis) to customer sites.
16) Proactively work towards agile best practices implementation from business analysis view.
17) Maintains good communication and co-ordination with team members, business partners and other stake holders as appropriate.
18) Contribute to all team efforts. Support and participate in collecting data related to organization metrics & adherence to scrum process.

19) Work with the supervisor to bridge the gaps identified in scrum process audits.

Sunday, February 4, 2018

User Stories

A user story is used to define product or system functionality and the associated benefit of the functionality.  In an Agile environment, projects are commonly comprised of a large number of user stories representing various levels of system/product user. This ever growing and prioritized list of user stories is called as product backlog. The user story describes the type of system/product user, what functionality they want, and why they want it. The format of a user story should be:

As a <type of user>, I want to <feature/function> so that <reason/value>

Sunday, September 3, 2017

Tribute to my Agile "guru"s

Guru (Sanskrit: गुरु. IAST: guru) is a Sanskrit (an Indian language) term that connotes someone who is a "teacher, guide, expert, or master" of certain knowledge or field. In pan-Indian traditions, guru is someone more than a teacher, traditionally a reverential figure to the student, with the guru serving as a "counselor, who helps mold values, shares experiential knowledge as much as literal knowledge, an exemplar in life, an inspirational source and who helps in the spiritual evolution of a student".

So why am I telling all this to you? My path in Agile transformations was filled with many challenges. It would not have been smooth if I did not get connected with such a Guru who was friend, philosopher, guide, mentor, counselor and coach to help mold agile values into me, to share his/her experiential knowledge as much as literal knowledge and to be an exemplar in life with an inspirational source.

I have came across many such Guru's and I want to pay a tribute to the most influential Guru's through this post. I want to sincerely thank each one of them for being part of my journey.


Chad Holdorf

Chad was my first guru. Chad was the one who showed me the first step towards the agile ladder. He told me the basic of agile manifesto and principles. And that's all. He never told me how to implement these principles, neither he told me how to conduct sprint planning, demo and retro. It was weird feeling in the beginning. But later I understood that it was all part of coaching Agile. Agile itself works on an empirical process control. So I learned that he wanted me to do experiments and learn, rather than doing a spoon feeding for me. This helped me understand different frameworks like scrum. Thank you, Chad!


Vibhu Srinivasan

Vibhu taught me scrum. He was my trainer in Certified Scrum Master class. He was the one who created solid foundation of scrum knowledge in my brain. He was the one who explained all the scrum rituals in a fun way. The training given by him included many table exercises which helped me to understand sprint planning, daily stand up, retro, story points, complexity, etc. I also learned from him on how to train somebody on agile-scrum. Thank you Vibhu!


Ashish Dhoke

Ashish showed me project management side of Agile. Until I met Ashish, I knew only scrum and kanban. This was the first time I learnt other siblings of Agile like DSDM, Lean, etc. He conducted 3 days of training on PMI-ACP for me and I never felt tired in the class. I also learnt the value part of agile from Ashish like ROI, IRR, etc. Getting certified by PMI would not have been possible without Ashish's guidance. Thanks Ashish!


Sachin Dhaygude

Sachin was (and is) a friend, philosopher and guide in my agile journey. He coached me on coaching skills. Sachin was the one from whom I was able to clear my thoughts around story point and relative estimation. He taught me soft skills as well which come handy while coaching anyone on Agile. His skill/art of explaining any difficult topic in a simple way amazes me always. I was able to put forward some of my ideas during his training, which I was not able to implement before, but after the training it was so easy to implement. Thanks Sachin!


Vineet Patni

Vineet is always looked at as an Agile evangelist. He coached me on ICP-ACC certification. His training was the most interactive training I had ever had. Vineet created the most brain damage during training. Vineet helped me to come out of project manager role and mold into an agile coach role. He used several real world examples to explain Agile principles and Agile mindset. I was able to relate with the human part of Agile. Thank you Vineet!


There are many more "guru"s to come. I will keep this blog post updated.

Wednesday, May 24, 2017

Scrum Master

"You will be scrum master of this from next week!" These are the words that you hear and then you find yourself in a mess. You really don't know what to do from next week? Your first reaction should be "Will I be a full time scrum master or a part time one?"

Wednesday, February 22, 2017

Definition of Done

Dear agile team, Don't let anything that's not DONE into your production.

In this practical and dirty world of software development, many roles work together on a user story and do their tasks to complete the user story. For a role, when s/he finishes his tasks, s/he might think that s/he is done. But we need some tool which will help the team and the product owner to get the confidence that a user story is really "Done" Done. With different members doing work that is "finished" at different times, how can the team and the Product Owner, know when a story has truly been completed?

Definition of Done (we will call it DOD henceforth) gives a confidence to the team and product owner that the story is done and can be released to production any time. Definition of Done is a list of things that must be finished before the work/story is accepted by the Product Owner. Merely testing the acceptance criteria can not ensure that the story is done. Acceptance Criteria is just a part of DOD. DOD also has lot of other things like -

Wednesday, August 3, 2016

Are we burning the right thing?

Is our development effort aligned with the business?
Are we getting good value out of our development team?
Is our team working on the right items?
Are we on the right track to get more value out of the team?
Are we burning the right thing?
Product Managers get a severe headache when these questions bang-bang their minds. Our development teams are usually great and great teams can deliver great software, but when the software delivered isn’t of high value the Business (i.e. the Product Managers) will still not be happy!

Tuesday, July 19, 2016

INVEST in user stories and perform SMART tasks

What is a good user story?

In scrum, we get married to user story. Have you ever thought of which story is good to get married and which is not? What are characteristics of a good user story? The acronym "INVEST" can guide you to identify the good stories:

I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable


Stories are easiest to work with if they are independent. Its better for them to neither overlap with nor depend on other stories and we should be able to schedule and implement them in any order.
We can not always achieve this. Once in a blue moon, we may say things like "3 points for the first screen, then 1 point for other screens."


A good story is negotiable. It is not an explicit contract for features. The details will be co-created by the customer and development team during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don't need these to prioritize or schedule stories.