![]() Instead of using tasks with estimated hours on it to track its remaining work, we use the combination PBI age + SLE to monitor if we will meet our forecast. If my PBI has been in the workflow for 3 days, I might not pay as much attention to it compared to another PBI who is now to its 7th day in the workflow. ![]() It has a calculated date range, 8 days or less, and a probability, 85 %.Īs a PBI is moving through the Scrum Team’s workflow, I use its current age in the workflow and compare it with its corresponding SLE to make sure it will meet its forecast.Īt our daily Scrum, we can use this forecast to keep track of our current work. To talk about forecasting at the Day and Iteration layers, I use the Service Level Expectation (SLE) as defined in the Kanban Guide for Scrum Teams.Ī service level expectation (SLE) forecasts how long it should take a given item to flow from start to finish within the Scrum Team’s workflowįor example, let’s say that historically, your development team completes 85 % of its PBIs in 8 days or less. SLE – The forecast at the Day and Iteration layers Teresa Torres’s Opportunity Solution Treeĭescribed in the fantastic read Continuous Discovery Habits, the Opportunity Solution Tree is a structured approach to build the right thing in a right way One of the best I’ve tried is the Opportunity Solution Tree (OST). There are quite a few models around that aspire to do just that. One can easily see that the best way to reconcile the two is to put OKRs first, dig up solutions that address both customer needs and business requirements and then put them in a document labeled the roadmap. When we talk about Objectives and Key Results, we want to define which problems are best to work on, somewhat independent of what the best solution is. OKRs on the other hand, are a problem-based approach to define the tasks that should be done. Now while the concept of a roadmap has changed a lot by the lean movement, it is still solution-based: any document labeled “roadmap” is one filled with solutions and maybe some fuzzy deadlines. It was a solution-based approach to define the tasks needed to be done. Traditionally, the roadmap was a prioritized list of features with due dates and deadlines that were to be built by the technical team.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |