Daily backlog prioritization

Currently I work with a team which its product is time sensitive for revenue generation. The requirements arrive in sporadic pattern and changes are the norm. Without going into the details of how effective product management is, we are required to deal with situation for increasing revenue.

Apparently we used Kanban for managing the product development of this team. We included 3 minutes for backlog prioritization as part of the daily stand-up, which served to:
– Address the volatility of cards prioritization, specifically mitigated the development of unnecessary cards.
– Product owner was able to have cards just-in-time when developers are about to have available capacity.
– Product owner managed to lower the speed of creating cards if development team is full so that she got chance to enhance requirements. This improved the quality of requirement to the development team.
– Reiterated that the team works on the highest priority cards.

A key policy is to provide the product owner feedback within a day from adding a new card. This has implemented technical risk assessment and meaningful collaboration between the team and product owner.

Gate Keeper

The product backlog is arguably the most important artifact for Agile team.

The problem is how to ensure that the product backlog timely includes all requests with their relative prioritization apart from their source.

This takes us to the product owner role in managing the hand-offs from demand to the development team(s) using the product backlog as medium of communication.

The biggest team complaint is that there are back doors for pushing requirements. This situation leads to:
– The team takes prioritization decision.
– Rift the team from following the value stream due to uncontrolled work as it’s not included in the visual board.
– Compromise the product by making the team working at low value requests.

As shown in the diagram, the product owner is responsible to coordinate with all possible sources of requests and translate their needs into prioritized backlog items. The backlog item is a card on the visual board and can either be MMF, Defect or Service. It is important to have explicit policies for each of these three types. Adding the dimension of priority (regular, target date and urgent) can add rules to these policies.

Finally, being a gate-keeper, the product-owner can ensure:
– The integrity of the product,
– Avoid adding requests which create technical debt,
– Assume ownership on the product acceptance, and
– Be considered by the team as the ultimate authority for clarifying requirements.


Risk based estimation

Although Kanban has been implemented in maintenance I still see there is advantage of implementing it in product development. For me I believe that Scrum provides opportunity to Lean approaches especially in the area is agile requirement development and management.

I prefer having high level business oriented requirements written by product managers who are closed enough to the client. I propose that once requirements are there, we should hold 1-2 day workshop with the whole team to:

1.       Introduce team members to the requirements.
2.       Complete risk analysis for each requirement and the related tasks.
3.       Prioritize requirements based on risks and business value.
Continue reading

Collaborate to create user stories


Collaboration is having dialog between two team members, not for the purpose to prove one’s idea, but instead to arrive at a third option. This third option would represent better thought. It is a result of validating one’ ideas with another and accordingly change your mind. The key here is that each person should be ready to be influenced by the other.

Collaboration in large teams is the collective results of dialog between members as pairs.

Team collaboration

To create product vision and stories it requires team collaboration between diverse members of varied interests. These members could include end users, customers, development teams, QA, designers, regulatories, management…. In addition user stories may be further classified to persona describing different usage patterns. Continue reading