I tend to instill the Lean mind-set into the act or may be art of Agile requirements management. User story workshop which we conduct shortly after developing the product vision can be very useful, because: Continue reading
Scrum was created based on the legendary paper here titled “The New New Product Development Game”. Notice that the word “new” is repeated twice emphasizing the target is for NPD. In our fast turnaround market, an NPD should not last more than 6 months and I suggest to have break-even within maximum of 6 months from completing the development. Continue reading
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.
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.
The product owner (PO) role requires multi discipline skills, for examlpe:
– Be responsible on deciding the right features at the right time
– Manage myriad of potential sources of requirements
– Product road map development
– Release planning
– Establish ROI from various features
– …… Continue reading
Going to the plain basics, maturity is to deliver what we promise. I heard this definition from a successful sales executive of product development company. For me this summarizes everything!
Meeting commitment is arguably the most important criteria for success. I use the measure of requests percentage which have deviation from target date exceed “x” days. This measure helps to quantify our maturity as organization. It represents the Voice of the Customer (VoC)
This measure can be organizational wide and it can be used to drive the whole improvement initiative.
The following chart gives high level analysis of causes of immaturity as suggested by this measure.
The foundational cause is the inability of people to timely communicate their issues. I worked with developers who had one month-long tasks and kept reporting that things are according to plan till they report failure at the very last day! I carry the responsibility by not allowing trust environment which encourages them to talk and share their concerns.
Sales people making commitment without consulting engineers is well-known issue which can be solved if they are educated about the capacity measures. These capacity measures can directly improve the above VoC measure. The capacity measures include Average Lead Time for each Class of Service. This measure allows sales people to provide informed estimates in the very narrow window that they might have to secure a deal. They can add percentage of uncertainty based on the inherent risks. I suggest this should be maximum of 20% with promise of being reduced as we proceed into the project.
Finally, a key assumption for failing to meet our commitment is the poor definition of customer valued request. Delivery on time requests which are not meaningful actually invalidates our improvement effort.