NoEstimates@iNatuix
Download as PPTX, PDF2 likes457 views
This document discusses the NoEstimates approach to software development. It begins by defining estimates and explaining that NoEstimates is about minimizing estimates rather than eliminating them entirely. The main goals of NoEstimates are to evaluate progress in a concrete way and force teams to slice work into smaller stories. Key benefits include being faster, easier iteration planning, and minimal time spent estimating. Progress is measured by the number of "Running Tested Stories" completed. The document also covers challenges, case studies, and debates around using NoEstimates versus more traditional estimating approaches.
NoEstimates@iNatuix
- 1. NoEstimates Compiled and Presented by Kamal Tejnani Agile Student Kamal.Tejnani@gmail.com 988 45 80802
- 2. Ground Rules • Lightning Talk for 10-15 mins • QnA at the end – please park your questions
- 3. Outline • What are Estimates • What is NoEstimates • Case Study on NoEstimates • Take on NoEstimates
- 4. What are Estimates ? ‘to give or form a general idea about the value, size or cost of something’ - The Merriam-Webster Dictionary From this, we can deduce that estimates are ideas. Sometimes those ideas are vague, and other times they are very precise or accurate, but they are ideas nonetheless. Hence, estimates are guesses, not facts.
- 5. Disclaimer • Not yet a proponent of NoEstimates • Just presenting another perspective on Estimates and Delivery
- 6. #NoEstimate - references The BookTwitter Handle – Woody Zuill
- 7. What is NoEstimate • NoEstimates is not about no estimation ever, but about the minimum amount of estimates that will do, and then look carefully at ways to reduce that need even more. • In essence this means not trying to estimate the size of the work; we just make sure we slice work into a size that we can bite on and turn around quickly.
- 8. Main Goal of the NoEstimates Movement • To help evaluate progress in a concrete – and easy to implement – way.
- 9. Benefits of NoEstimates • It is faster. • It also forces teams to slice into smaller stories. • Iteration Planning becomes even easier, because you just need to understand your velocity and how many stories you can fit. • You spend minimal time estimating.
- 10. How to measure Progress • “Working software is the primary measure of progress” RTS Stories (Running-Tested-Stories ) is the equivalent of this and is the only metric used in NoEstimates • 1. Requirements need to be written in a way that allows you to measure progress early and often during the project. • 2. Requirements need to be written in a way that provides you with the necessary flexibility to make decisions on what part of each requirement will be implemented later, when you better understand the system, and the business needs.
- 11. NoEstimate – Progress revisited • deliver several stories per week • assess the time it takes to deliver multiple Stories, which would in turn help forecast future progress. Slice your Features and user stories so that you can review progress on a daily or at least weekly basis. In practice this means that every week several stories should be completed to allow you to assess progress. And every few weeks (every month or so) several Features should be completed.
- 12. How to measure Progress Running Tested Stories (RTS)
- 13. When will the Project be delivered – Progress Revisited • How many User Stories can a team deliver on an average week? (The User Story velocity). • How many Features can our project deliver on an average week? (The Feature velocity) • Is the feature comprising of the user stories the smallest, largest or medium feature – Extrapolate remaining work based on this.
- 14. NoEstimates Principles • No Huge Stories Each Story is small and all Stories are pretty homogenous in size which means that you can focus on their Value instead of their cost in making a decision • Independent Stories in a Sprint. Each Story can be dropped from the project without affecting the overall project delivery • Target 1 RTS per team member per day – look out for 0 RTS for one or more team members for more than 1 or 2 days • Approximately same number of small-medium-big stories in each Sprint
- 15. NoEstimates – INVEST principle redefined • NEGOTIABLE o Define a very clear capability for the system, but do not dictate an implementation strategy, or very specific functional requirements. o This property allows the development team to select an implementation strategy that best suits the project when the time comes to implement that Story, and o allows the customer to be engaged in defining the detailed functionality later on based on the running demo of the software. • ESSENTIAL (instead of Estimable): o A story must not only be valuable, but it’s removal must make the product unusable or unsellable. • SMALL o Stories should be between 0,5 and 1 man-days of effort. Establish that as your target, and slowly move towards that size. Your visibility to progress and quality will slowly increase as the size of the Stories decreases.
- 16. NoEstimates - Workbook • What is the most important value to be delivered by the project from the customer’s perspective? (Purpose of Each Release) • When does the project need to go live with the first release? • What does the customer expect to accomplish with that first release? • How many, and which, Running Tested Stories (RTS) do you need to deliver until that first release? • How many RTSs have you successfully delivered during the last 2 months (the length of the project until then)? For example, if you have 10 weeks to the next delivery and you have 20 Stories that should go into that delivery, you know you need to deliver an average of 2 Stories per week to make that delivery. If you deliver less, you should then evaluate the scope and make the necessary reduction. If you deliver more, you are on target and may be able to deliver more functionality at the end of the 10 weeks. The first question about the purpose of each release is the most important. By understanding the goal of your customer you will be able to “steer” the delivery by evaluating, prioritizing and ultimately removing Stories from that delivery. Without an answer to the first question, the most important tool for the #NoEstimates practitioner (scope management) will not be available.
- 18. Blink Estimation “does this Story feel like it could fit into a 2-week sprint?” If the answer was yes, we took it in, if not, then we broken it down further. Not much time was wasted in those conversations; the goal was to get started doing the work to assess if we were indeed able to deliver that Story in 2 weeks. …having a consistent rate of progress is more important than estimating a project. This consistent rate of progress will help steer the project in a very concrete way
- 19. NoEstimates – Multiple Levels of Granularity • Features – that cannot be delivered in a n-week Sprint • User Stories – that can be delivered in 0.5-2 day(s) within a Sprint Approx. 2 stories being delivered per day
- 20. Rolling Wave Forecast • At the heart of the rolling wave forecast is the acceptance of uncertainty • Create Scenarios of the Future • Speculate how events will unfold and evaluate possible outcomes for the different events • This forecasting mechanism allows the project team to know when they are likely to deliver a certain Feature and therefore also coordinate work with external project contributors.
- 21. NoEstimates – based on lessons learnt … • only when we start working on a Story that we actually know how long it will take to deliver • breaking down Stories helps us assess progress at the project level faster, and make the necessary (and inevitable) scope decisions. Not all stories are critical • Finally, having a consistent rate of progress is more important than estimating a project. This consistent rate of progress will help us steer the project in a very concrete way: reduce work or re-prioritize work based on actual progress data, instead of a guess at a plan that will invariably change
- 22. Challenges to doing NoEstimates • Thin Vertical Slicing of User Stories as RTS of 1-day duration • Creating Independent Stories of homogenous size (if 1 day ? ) • Historical data especially if features to be delivered are different, technology is different, team might be different etc. • Customer will accept reduced scope delivery
- 23. Case Study #1 using NoEstimates http://www.qondor.com/ A travel and event management tool used by industry leading companies across 9 countries, including Egencia / Expedia, the largest travel management company in the world. The system is mission critical to the users - if the system stops working, they will not be able to do their job.
- 24. Case Study #2 using NoEstimates • Don Wells, an early Extreme Programmer who worked on the Chrysler Comprehensive Compensation System project (the birthplace of XP) Each week we just choose the most important items and sign up for them up to the number from last week. It turns out that we get about the same number of them done regardless of estimated effort. We have 1 week iterations so we tend to break things down a bit at the iteration planning meeting. …. the point is we get about 8 things done each week, no estimation required.
- 25. Does NoEstimates answer these … To know when we can release software to our users (Missing the season ?) What it will roughly cost to develop and deliver the software (Budgetary Constraints) For Proposals (Can you say I will not give a quote ? ) Boss/Client wants it …
- 26. Arguments against NoEstimates • What if Customers WANT estimates “Customer Collaboration over Contract Negotiation” – if customers want estimates, we have to give them estimates A US based large Financial institution outsourcing development and testing work to India using a T & M mode They will “want” estimates • If a lot of the estimates are inaccurate - So should we not improve estimation • The time spent creating estimates is wasted But if you get better at estimating, you’ll spend less time producing better answers and the time won’t be wasted
- 27. #NoEstimates versus #Estimates debate • In which projects #NoEstimates work • Can #NoEstimates work in big projects • Need more case studies for #NoEstimates
- 28. Estimates – a simple case study • Suppose a family wants a kitchen to be built comprising of drawers, exhaust, floor cabinets, wall cabinets, water filter compartment, gas cylinder cabinet, steel sink • Budget is Rs. 2 lakhs. Can we tell the family to prioritize everything and then we will continue doing things in the order of priority and it will take as much money as it takes. At least some indication needs to be given
- 29. Kamal’s take on NoEstimates • RTS I have been doing this for a long time Estimations I do Relative Sizing at the Release Level and Task driven Capacity at the Sprint level. The teams are empowered to not allow anyone to arm twist them to take up more work than what they think they can commit
- 30. NoEstimates – Further Learnings • The Ultimate Guide to Capacity Planning with NoEstimates by Tomas Rybing • The #NoEstimates Pioneers on Video: o Woody Zuill, the creator of the #NoEstimates hash tag on twitter o Neil Killick, the creator of the Slicing Heuristic, a great way to reach #NoEstimates quickly • Henri Karhatsu, greatly experienced #NoEstimates practitioner with many stories to share • 4 video interviews with #NoEstimates practitioners o Chris Chapman o Marcus Hammarberg o Allan Kelly o Clinton Keith • 2 video interviews with CEO’s that apply #NoEstimates in their own organizations o Sven Ditz, CEO of Sitegeist.de in Germany o Diego Cenzano, CEO of biko2 in Spain .
- 31. THANK YOU Q n A