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.
For me sizing can be useful if and only if no risks are associated with the requirement, which is rare. After putting aside requirements having risks, the team can start immediately working on high priority requirements which have low risks. During that time risk resolution can take place between product manager, engineering and of course customer.
Typical risks encountered can be classified as:
1. This requirement can lead to significant redesign change to develop. However, if the client can agree on different flavor of it, then, the change is limited.
2. External dependencies, which are outside of our control, but needed to complete the development of this requirement.
3. Internal dependencies on other teams within the organization, example Build and Release group.
4. Technical challenge for the team members to develop this requirement.
5. How to provide generalized design for the requirement so that it can expand with low cost during maintenance?
6. How would be able to test the requirement?
7. The team can receive maintenance requests during the development. How to retrofit these requests to the new product?
8. No thorough understanding about the client environment.
9. Is the team capable to implement the appropriate Definition of Done?
10. What is required to be completed by the development team so that the product can be implemented by the client or support engineers?
Failing to appreciate requirement risk is the first step in creating our own Technical Debt,yet alone affecting both project deadline and client acceptance.
Risk based sizing is a way to align business realities with the technical aspects of software development. Failing in this alignment narrows the development scope as it limits team members’ imagination to foresee impending issues from the above risks.
Risk discussions create collaboration and promote ownership on the requirements by focusing on addressing the real issues. Risk analysis promotes understanding of the team capability as related to the desired ability to develop and implement the product.