Product Owner

Planning Poker is NOT about Agile Estimation!

One of the popular mechanisms to estimate story points as a team is planning poker exercise.

It’s an awesome technique but it may become a challenge for some teams. For instance, a team estimates story points separately as developers and testers. Later, they add up those points to arrive at resultant estimates.

Some teams get into endless discussions to ascertain if the estimate should have been 2 or 3, 5 or 8 or maybe 7.

It looks like, the primary goal of planning poker exercise is to arrive at the correct estimate.

But that’s not the point!

Streamline Your UAT and DevOps – Kanban Boards

by Avienaash Shiralige 4 Comments

In my earlier post, we discussed using planning boards to improve your backlog planning and eventually to improve your planning flow. Main project workflow remained same.

Note: People landing on this post directly, please read earlier post to get context of the problem.

This team was using 2 week sprint model for execution. Often stories got completed(tested), but left on the scrum board UAT pending. All real users were on-field consultants, hence not easily available for UAT. This reduced team throughput(velocity). Team decided to change their approach and modify their definition-of-done. They decided to have a done column before UAT. Post demos relevant stories were moved to done. In-fact they did multiple demos to product owner all through out the sprint as stories got completed. They configured their execution scrum board as shown below.

Use Planning Board for Product Backlog Grooming

by Avienaash Shiralige 4 Comments

In our earlier post – Improve sprint throughput we had discussed about how important it is to have stories ready for play before team picks it as part of the sprint. In short, if half-cooked stories are pushed to sprints for execution, then team will spend lot of time analysing, re-working and this eventually reduces team throughput. To address this challenge, few of my teams thought of creating a separate planning board in Jira to track planning readiness. This board was used by PO primarily to keep a tab on the backlog and also by team members during backlog grooming session.

Team was using Atlasssian Jira, I will show here how we modified the workflow and boards within Jira. Some of the issues teams had faced with the backlog not being ready were:

Insufficient scenario analysis in user stories
Lack of functional and technical impact analysis
Not much details/mocks within the story
Team doing sizing estimate during sprint planning – this was the first time team was seeing those stories and hence made sprint planning long and inefficient

Hence a workflow was designed to address above issues. Take a look at the workflow below(pasting it from Jira).

Improve Sprint Throughput with “Definition of Ready”

by ShriKant Vashishtha 4 Comments

Teams are obsessive towards better customer satisfaction and rightly so.

High team value throughput is one of the important ingredients towards better customer satisfaction. Before we move further, let’s look at what throughput means in business context. According to Wikipedia:

Throughput can be best described as the rate at which a system generates its products / services per unit of time.

In order to achieve better throughput, it’s implicit to look inwards, within the development team. However some improvement areas may lie in other quarters.

Product Ownership is one such area which may have a massive impact on a team’s throughput. In this post we’ll look at throughput impact and will discuss how it can then be solved through “Definition of READY”.

Context

For lots of Scrum teams, the Product Backlot Items (PBIs) may not have sufficient clarity before moving to a sprint. For cases in which the Product Owner and rest of the stakeholders are sitting next to the development team and easily accessible, the Scrum team can work together to get the required clarity during the sprint.

However in lots of other cases:

the Product Owner may not be able to spend enough time in shaping the product backlog. He’s also not able to spend time with the development teams in clarifying their doubts on the Product Backlog. This can happen because of various reasons.
the Product Owner and rest of the stakeholders may be sitting in different parts of the world. They may not be easily accessible because of time-zone differences and lots of handoffs, and each-one having their own priorities.

All these scenarios almost immediately impact the sprint execution.

As Product Backlot Items (PBIs) are not clear enough, the team begins with half baked information.

In such cases, something which could be finished within 2 hours (if all information readily available), may take a week to complete while clarifying those questions in between.

This resultant lack of sufficient information impacts the team throughput. The development team on their own can’t do much in such a context.

However, it would help the development team a lot, if they could have a definition similar to Definition of Done on the PBI level as well. That way only those PBIs which have sufficient information available for the development move to a sprint. That definition is “Definition of Ready”.

What is Definition of Ready

The Definition of Ready is similar to the Definition of DONE, but with the following differences.

In case of Definition of Done, the Scrum development team creates a DONE increment for the customer.

For the case of Definition of Ready, it’s the Product Owner who is accountable in shaping READY PBIs for the development team.

In other words, any PBI coming inside Sprint backlog has to be READY and any PBI moving out of Sprint must be DONE.

In order to come up with “READY to play” PBIs, the team conducts regular backlog refinement sessions with the Product Owner.

The simplistic “Definition of Ready” looks something like this.

When is a PBI Ready?

In general, a PBI is ready when following conditions are satisfied

The Product Backlog Item (PBI) has value.
The PBI is immediately actionable by the team. The team is clear on the functional as well as non-functional understanding of the PBI.
There is no outstanding question/dependency remaining that could stop the team from working on the card, be it test/dev or whatever.
The PBI has acceptance criteria and it has been discussed along with the team during backlog refinement conversation.
The Scrum team has discussed it together.
The PBI is sized (in story points/ t-shirt sizing etc)
The PBI is small

In general it’s the team which decides whether the PBI is ready or not.

Only ready PBIs become the candidate of the sprint planning

The Readiness of Product Backlog

A Product Backlog is “Ready” if it has enough Product Backlog Items at its top, meeting these criteria, to fill a Sprint.

Note that all PBI in the Product Backlog do not have to be Ready, though as they move up the Product Backlog, they should progress toward becoming Ready.

Definition of Ready is Mandatory in a Multi Time-zone Distributed Agile

It’s quite common to see completely opposite views from Agile purists on Definition of Ready as they believe that it is not required at all.

That may be true to some extent for collocated teams supported by dedicated Product Owners available when required for clarification in the same time zone.

However, distributed Agile in different time-zones is a different beast altogether. It’s quite common for such teams to work with customers in opposite time-zones. Distributed communication in such cases introduces delays.

So the clarification which you receive in minutes face-to-face with the collocated Product Owner may require multiple iterations of distributed communication. Multiple iterations sometimes mean multiple days.

So a READY PBI which could be finished in 2 hours now may take days to complete because-of to and fro communication between distributed team-members to resolve unresolved queries.

The difference in such cases is all about between holding cost and transaction cost. In distributed multi time-zones teams, the transaction cost of distributed communication for getting questions answers through a Product Owner tends to be high. That’s the reason, the team tends to keep (hold) a bunch of PBIs ready for the planning purposes so that sprint time doesn’t go waste in to and fro communication but the team is able to focus on getting things done.

Definition of Ready in such cases helps in bringing clarity and helps in keeping team members and the product owner on the same page. Any absence of clarity essentially introduces long delays and impacts the throughput of a sprint.

Agile Offshore: Create Effective and Decisive Product Owner Proxy to Offshore Team

by Avienaash Shiralige 6 Comments

Off-shoring in current market is a global economic and strategic need. Building Agile Offshore teams across boundaries and time zones is a different ball game. It has its fair share of challenges to work with. I shared few of those challenges and a possible approach to take in my earlier articles.

1. How to Address People and Communication Challenges
2.Distributed Agile:10 Best Practices of Successful Teams
3. Distributed Scrum: A Day In The Life Of A Distributed Team

You need to make few changes along your way to your normal routine to make it work. One challenge I often see is integration of offshore team with onshore team and to project/business vision.