Hey Product Manager, is your backlog mature?

As the world embraces the Agile methodologies with gusto, it is important to get certain elements right to ensure that the key Agile principles are properly implemented. One such element is Transparency. A mature Product Backlog goes a long way in ensuring transparency.

For the beginner, a Product Backlog is a wish list of features or enhancements that would make your product great. It contains User stories which are features or enhancements written in the language of the end user. Contrary to Waterfall projects which have a baselined and frozen list of requirements, the Product Backlog is kept alive and constantly modified through the life of the Product. It is this changing nature of the Product Backlog that is both an asset and a potential liability. It is important to ensure that the Product Backlog does not become just a stale document of EVERYTHING that might or might not get implemented in the product’s lifetime. It is the Product Manager’s responsibility to maintain a mature backlog and once done, everyone involved in the organization stands to gain from it.

3086708145_5ed56e5e5f

With this background, I shall now attempt to define the characteristics of “A Mature Product Backlog”.

Valuable User Stories: A Mature Product Backlog contains user stories that deliver value to the customer. Each user story should take the product one step closer to the product that the end user desires. Additionally, each user story should have Acceptance criteria clearly listing the boundary conditions, performance criteria and other quality expectations.

Prioritized Backlog: The Product Backlog should be prioritized by the Product Owner in terms of the highest value stories at the top of the list. Another factor to be considered is the Risk involved in implementing the user story. It is a good idea to categorize user stories on Value and Risk and then prioritize the backlog on Value first and Risk next. High Value Low Risk stories would be at the top with the Low Value High Risk stories at the bottom.

INVEST(ed) User stories: A mature Product Backlog has user stories that follow Bill wake’s Independant, Negotiable, Valuable, Estimable, Sized appropriately and Testable (INVEST) mnemonic.

A definite list: The backlog is a list of user stories that will make your product great and it is not possible to only have a certain number of user stories in it. However, instead of having an endless list of small and big features, all I want you to do is a) Keep features that are due to be implemented in the current Release very detailed, b) Group similar features that are part of future releases into Epics and c) Keep user stories from future releases big and break them down into smaller user stories only as you come close to implementing them.

Estimated User stories: This is an Optional requirement for a mature Backlog. It is great to have a Product Backlog with user stories that are assigned story points to determine the size and effort involved. This helps the Product Owner in prioritizing the user stories. For estimating a large number of user stories, Planning poker could be ineffective and the Affinity estimating technique will be a better method.

Over to you now. do let us know if something is missing in this list.

(Pic: Thanks to Flickr: Creative Commons for the Backlog pic)

Who let the product die?

One evening, few products who registered to the Products Anonymous forum met at a local cafe to introduce themselves and share their experiences. They started off in a round robin fashion and we shamelessly listen in…

I died as I arrived as I did not serve any significant purpose for my users. People did not pay for me as they were convinced that I am not good as existing products they were using. Few who dared to risk by buying me but they did not like me. I am result of reactive product manager.

I made good sense to my buyers and they too fell in love with me but none took me home simply because they could not take me home. I did convince them about benefits that I can bring to them and they did agree to most however owning was not so cheap. Their hands did go in their pockets but only few could come out. I wish I could have been better priced but my over confident product manager thought otherwise.

I made success the moment I hit the stores and I was at all the places. I was talk of the town. This was 2 years back, the same people who rushed to shops 2 years back to buy me are the one who hate using me. It is not that I am a bad quality product but like all other products I too need some maintenance which my makers really did not bothered about. My buyers find it hard to repair me or replace my parts, my mechanics are difficult to reach and they simple do not live up to my buyer’s expectations and my product manager believes customer satisfaction is not his responsibility. I am suffering because my product manager never bothered about customer satisfaction.

People liked me and they want me. Few took me home but returned me to the store simply because they find me little too complex to set me up, forget using me. And for those who could configure me correctly found difficult to use me. I know I am a good quality product but at the same time I am difficult to use. My product manager could never appreciate importance of user experience and even though I am efficient I died premature death as I was made me so complex for my users.

I was created so well by makers that I never thought I will spend most of my life in warehouse. Somehow my product manager screwed up big time. He put me in the wrong shelf. He should have put me in the second from right shelf instead he put me in second from left shelf. Pathetic, people who came buying me could not understand my need to be on second from left shelf and those who went to shelf at second from right could never find me. This guy made me nice but could never understand my use. My product manager only had technical sense but marketing sense was missing big time.

I was born with bad luck or shall I say bad timing. The day I hit the shelf I was liked by buyers but most refrained from picking me for simple reason that they knew what my product manager did not knew. There was something new coming in few days and most anticipated that product to be better than me. As a result no one picked me and though I was at par with my competition I did not gain enough word of mouth and eventually lost the batter. My product manager’s ignorance killed me.

All went well for me but I still could not make it big. I was good but business leaders never believed in my potential or success. They always wanted a reason to shut me down and my product manager never bothered to advocate about me to executive team. I died slow with great pain. I could only wish that my product manager should have been stronger in advocating me.

@mathurabhay

3 Key Personality Enhancements from Agile

All over the world, Agile methodologies are changing the ways of working and are leading to faster value realization for both the businesses and customers. The value that Agile methodologies are bringing is evident from the fast paced and the high volume of companies and organizations adopting Agile.

Scrum-personalImpr

However, the angle that we are looking at here are the personality improvements that individuals get from being in an Agile team. These are traits that team members get from working in a self organized Scrum team and will be an asset for life. These traits are visible across most flavours of Agile, but we shall stick to Scrum for the moment.

Small steps with feedback: Scrum advocates frequent small releases to market with valuable content rather than one big release at the end of the project. This way, each time a small release is made, feedback is obtained and is ploughed back into the product to make it better. Scrum teaches you to take small steps towards the goal, not relying on one big jump at a later point of time. Scrum understands that planning is important, but it is more important to get moving. Similarly, with each personal goal, it is good to identify the goal, break it down into smaller parts, implement them one at a time, observe the results and fine tune or change the goal as needed. Many times, the personal goals and resolutions need constant reminding and by making frequent small changes, you are not only keeping the goal alive, you are also taking steady steps towards the final goal. As Ralph Waldo Emerson puts it “An ounce of action is worth a ton of theory”

Effective Improved Communication: Scrum puts power into your hands as a team member. To exercise this power, you have to talk and express yourself in planning and estimation sessions, make your voice heard in daily stand-up meetings and voice your opinions in Retrospectives. Scrum’s rituals are all about being heard without being dominant. Initially, it might be hard for some team members to lose their inhibition, but Scrum’s daily stand-ups, planning meetings and retrospectives urge each one to open up and participate. In a positive way, team members are forced to open up in a trusted team environment and over time, this gives confidence to individuals to be more expressive in bigger groups and forums. Voila, Scrum has made you a better public speaker.

See the other person’s perspective: A team composition in Scrum consists of subject matter experts (SMEs) in Development, Testing, etc. As they plan together and work together Sprint after Sprint, they orient themselves towards the Sprint goal each time. With this, once a person is done with his/her task, he/she is now looking to pick up and contribute towards any other task that needs to be completed to meet the Sprint goal. The team member is picking up new cross functional skills and looking at things in a new perspective along with contributing towards the Sprint goal. Development and testing silos are broken and the team becomes self organized. Each person is able to understand and appreciate the other’s views and experience.
This experience teaches us to think more broadly when we face a situation in life where instead of criticizing a person who holds a different perspective, we try to put ourselves in his/her shoes and think from their perspective. Though this is no rocket science, the experience from working in an Agile cross functional team allows us to pause and listen to a perspective that could be valid and totally different.

Do let us know how your personality has gained by working in an Agile environment.