If the task proves any bigger it will need broken down. This is likely greater than a week's worth of work. Ivan Bienco, one of our developers, created the following table to help explain the Fibonacci Method to new onboards: Points If a developer is unsure whether something is “five ” or “eight”, we encourage them to err on the side of caution, especially when they are first getting used to this system. The idea is that it's much easier to decide quickly if something is five versus eight points than it is to decide if something is five rather than six points. We use the Fibonacci sequence (1, 2, 3, 5, 8, 13, with our scale ending at 21) to determine "level of difficulty" in story points. When we plan a sprint, every ticket is assigned “story points”. We instead have opted to track “level of effort” (LOE) as our back of the napkin estimation technique. Additionally, if work changes hands at any point, one person’s “week of work” could be twice as much time as someone else’s.
“Time” may vary for similarly difficult tasks depending on how much concentrated time is devoted to it, or whether the difficult part is the planning stage or actual implementation. We use the Atlassian stack, so we’ve adopted their terminology (Sprint, Scrum, Project, and Board are in heavy use in my vocabulary)Īt SpiderOak we’re running on the theory that “time” is inherently trickier to predict than “effort”. One of the benefits of sprints and other short planning periods is the very fact that you have a built in opportunity to stop, reassess the situation, and change direction as needed to reduce the impact of cascading delays. Worse, some stomach bug is sweeping the office and now the whole project is five days behind schedule.Įstimation is plainly and simply a skill that can (and needs to) be honed. Now, Engineering is going to get the work two days later than expected, but they still need the three weeks they quoted and don’t have wiggle room to “save” the two days back. After three days’ effort the team realizes there’s a cleaner, more user-friendly option and they have to rework some of what they’ve already completed. Waterfall methods which necessitate one team finishing their work before another even starts can result in pushing a careful year-long plan off target every time something is delayed by even one day.Ĭonsider this scenario: Design promises completed wireframes, specs, and components in two weeks. Additionally, any schedule has the potential for cascading delays based on dependencies. If we hold fast to planning, the machine runs smoothly but a given fire may burn for a while before it’s resolved. You can’t plan for everything, and interruptive work skews carefully made predictions, but if we allow every fire that crops up to push out planned work, we cannot reliably deliver on what we’ve committed to during planning. Other departments with dependencies based on your work will need to know when to expect your team’s portion, so you may as well foster harmony and learn to estimate accurately. Marketing will need to plan campaigns to line up with a major release. Sales will need to reliably tell a prospect when they might expect a prototype. Your board will want to know when you expect to go to market. So why plan at all? There are parts of your business that will always need timelines. Interruptive work that is the newest hair-on-fire-priority push planned items behind schedule or, more simply, estimates can be wildly inaccurate. In her presentation, Poppendieck suggests that meticulous plans spanning months into the future fall apart when cascading dependencies or changes in direction subvert careful calculations. An excellent example from Mary Poppendieck can be found here.
There are many brilliant and in-depth articles out there explaining more eloquently and in greater detail the theory behind planning successes and failures. Off-the-cuff estimate requests can be stressful are you better off to overestimate and risk a long explanatory conversation? To give a quick estimate and cross your fingers you won’t be held to it if you discover there was a lurking dependency? Does “I don’t know” send the message that you are unable to plan reliably?
It’s 4:30PM on a Friday and the Sales representative working with your department says “I have a client meeting Monday – can you tell me how long it will take to implement the new feature we talked about today?” Groan.
0 kommentar(er)
