Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile projects | Prioritization
Similar to Agile projects | Prioritization (20)
More from XPDays
More from XPDays (15)
Recently uploaded
Recently uploaded (20)
Agile projects | Prioritization
- 2. Presented By & Introduction Agile Projects | Prioritization It's an initiative for gathering people interested in Agile, eXtreme Programming (aka: XP), Scrum, Coding, etc. The Idea of XP Days was found at November 2019 and since that we have conducted lots of knowledge sharing meetups and webinars. This is our 16th meetup. Agile Arena is an Agile Consulting and Training company. We specialize in agile adoption and transformation for companies and teams through: • Designing their agile adoption programs • Executing our programs and guiding the team through their journey to sustainable agility . • We also provide training for teams and individuals to help them coping with the agility trend in the market.
- 3. This Webinar is Held By: Ahmed Helmy Software Consultant Founder of XP Days
- 4. Presented By & What do your expectations for today? Agile Projects | Prioritization DISCUSSION
- 5. Presented By & AGENDA • Prioritization Factors • MoSCoW Scheme • Kano Model Agile Projects | Prioritization What we’ll be covering this webinar
- 6. Presented By & Agile Projects | Prioritization Scrum Artifacts Sprint Backlog Increment Product Backlog Product Goal Sprint Goal Definition of Done
- 7. Presented By & Why do we prioritize? Agile Projects | Prioritization DISCUSSION
- 8. Presented By & How do you prioritize? Agile Projects | Prioritization DISCUSSION
- 9. Presented By & What is business value?! Agile Projects | Prioritization DISCUSSION
- 10. Presented By & Agile Projects | Prioritization “The indispensablefirst step to getting what youwantis this: Decide what you want.” - Ben Stein
- 11. Presented By & Agile Projects | Prioritization Prioritization Factors Knowledge Value Risk Cost
- 12. Presented By & Agile Projects | Prioritization • This alone is often what is meant when product owners are given the advice to “prioritize on business value” • How much money will the organization make or save by having the new features included • Estimate its financial impact over a period of time, usually the next few months, quarters, or possibly years Value
- 13. Presented By & Agile Projects | Prioritization • Many features seem wonderful until we learn their cost • The best way to reduce the cost of change is to implement a feature as late as possible Cost
- 14. Presented By & Agile Projects | Prioritization • Product knowledge • What will be developed • Features that will be included, and those that will not be included • Project knowledge • How the product will be created • Technologies, skills, and how will the team functions together • End uncertainty is reduced by acquiring more knowledge about the product • Means uncertainty is reduced by acquiring more knowledge about the project Knowledge
- 15. Presented By & Agile Projects | Prioritization Knowledge Acquiring new knowledge is important because at the start of a project we never know everything that we will need to know by the end of the project
- 16. Presented By & Agile Projects | Prioritization • Schedule risks (“we might not be done by October”) • Cost risk (“we might not be able to buy hardware for the right price”) • Functionality risks (“we might not be able to get that to work”) • Technological risks • Business risks Risk
- 17. Presented By & The four quadrants of the risk-value relationship Agile Projects | Prioritization
- 18. Presented By & MoSCoW Prioritization Scheme Agile Projects | Prioritization Mo “Must-have” requirements are the highest in priority, the essential requirements for the system to work S “Should-have” requirements are those that are required for the system to work correctly as intended Should have requirements can be as important as Must have, however they are often not as time-critical or there may be another way to satisfy the requirement Co “Could-have” requirements are those that improve the user experience and obtain more customer satisfaction They could be included if the time and cost permit W “Won’t-have” this time: those are the least critical, lowest payback items that won’t be included into the next delivery time-box
- 19. Presented By & Features categories Agile Projects | Prioritization • Must-have: a bed, a bathroom, a desk, clean • The more the better: comfort of the bed, size of the room, variety and quantity of equipment in the fitness center • Exciting: built-in televisions on the treadmills, free bottle of water in my room each day
- 20. Presented By & Kano Model of Customer Satisfaction Agile Projects | Prioritization
- 21. Presented By & Agile Projects | Prioritization www.agilearena.net www.xpdays.org
- 22. Presented By & DISCUSSION Agile Projects | Prioritization OPEN DISUCSSION
Editor's Notes
- There is rarely, if ever, enough time to do everything. So, we prioritize.
- There is rarely, if ever, enough time to do everything. So, we prioritize.
- “prioritize on business value.”
- To provide a more practical set of guidelines for prioritizing. We will look at four factors that must be considered when prioritizing the development of new capabilities. The financial value of having the features The cost of developing (and perhaps supporting) the new features The amount and significance of learning and new knowledge created by developing the features The amount of risk removed by developing the features
- This alone is often what is meant when product owners are given the advice to “prioritize on business value” How much money will the organization make or save by having the new features included Estimate its financial impact over a period of time, usually the next few months, quarters, or possibly years
- Many features seem wonderful until we learn their cost The best way to reduce the cost of change is to implement a feature as late as possible
- Acquiring new knowledge is important because at the start of a project we never know everything that we will need to know by the end of the project Knowledge about the product, and Knowledge about the project Product knowledge What will be developed Features that will be included, and those that will not be included Project knowledge How the product will be created Technologies, skills, and how will the team functions together The flip side of acquiring knowledge is reducing uncertainty Uncertainty about what features the product should contain (End uncertainty) Uncertainty about how we will build the product (Means uncertainty) End uncertainty is reduced by acquiring more knowledge about the product Means uncertainty is reduced by acquiring more knowledge about the project
- Acquiring new knowledge is important because at the start of a project we never know everything that we will need to know by the end of the project Knowledge about the product, and Knowledge about the project Product knowledge What will be developed Features that will be included, and those that will not be included Project knowledge How the product will be created Technologies, skills, and how will the team functions together The flip side of acquiring knowledge is reducing uncertainty Uncertainty about what features the product should contain (End uncertainty) Uncertainty about how we will build the product (Means uncertainty) End uncertainty is reduced by acquiring more knowledge about the product Means uncertainty is reduced by acquiring more knowledge about the project
- Schedule risks (“we might not be done by October”) Cost risk (“we might not be able to buy hardware for the right price”) Functionality risks (“we might not be able to get that to work”) Technological risks Business risks Should a project team start by focusing on high-risk features that could derail the entire project? Or, Should a project team focus on - the juicy bits – the high-value features that will deliver the most immediate bang for the customer’s buck? Risk-driven team accepts the chance that work they perform will turn out to be unneeded or of low value. They may develop infrastructural support for features that turn out unnecessary as the product owner refines her vision of the project based on what she learns from users as the project progresses A team that focuses on value to the exclusion of risk may develop a significant amount of an application before hitting a risk that jeopardizes the delivery of the product The solution, of course, is to give neither risk nor value total supremacy when prioritizing
- High-risk, High-value features are highly desirable to the customer but posses significant development risk. Perhaps features in this quadrant rely on unproven technologies, integration with unproven sub-contractors, technical innovation (such as the development of a new algorithm), or any number of similar risks The high-value, high-risk features should be developed first. These features deliver the most value and working on them eliminates significant risks Finally, features that deliver low value but are high-risk are best avoided
- How to prioritize work for a new product release Threshold, or must-have, features Linear features Exciters and delighters Product price is often related to linear attributes The lack of an exciter or delighter will not decrease customer satisfaction below neutral Exciters and delighters are often called unknown needs because customers or users do not know they need these features until they see them Once some amount of a must-have feature has been implemented, customer satisfaction cannot be increased by adding more of that feature. Also, no matter how much of a must-have feature is added, customer satisfaction never rises above the mid-point Customer satisfaction rises dramatically based on even a partial implementations of an exciter or delighter Direct relationship between the inclusion of linear features and customer satisfaction Because must-have features are required for a product to even play in its market segment, emphasis should be placed on prioritizing the development of all threshold features they need to be available before the product is released. Keep in mind, though, that partial implementation of must-have features may be adequate since gains in customer satisfaction drop off quickly after a base level of support for threshold features has been established Secondary emphasis should be placed on completing as many linear features as possible. Because each of these features leads directly to greater customer satisfaction, the more of these features that can be included, the better. at least a few delighters should be prioritized such that they are included in the release plan. Keep in mind that features tend to migrate down the Kano diagram over time. A short time ago, wireless Internet access in a hotel room was a delighter. Now it’s a linear feature well on its way to becoming a threshold feature.