I adore Mike Cohn from Mountain Goat Software. He writes articles that make you go "Hmmm." I like to share the ones that hit home to me on my blog. This post is Mike Cohn's article about why teams underestimate work. I find this a common issue with teams. It is defeating to a team when iteration after iteration they cannot complete the work they signed up for. In my experience #2 "Lack of clarity about the feature" is fairly common. User stories have not been refined and the requirements are too vague. When this happens, teams have to spend time getting clarity, which means meetings, and more meetings, and then someone mocking it up. Read more to see how you can help your teams.
https://www.mountaingoatsoftware.com/
=============================== Many teams underestimate their work. It happens both when estimating product backlog items (most commonly in story points) and during sprint planning when identifying tasks and estimating them in hours. This week I want to highlight seven reasons many teams systematically underestimate. 1. Overconfidence. Team members often think they know more about a feature than they really do. 2. Lack of clarity about the feature. Product owners don’t usually know everything about how a feature should perform. If the product owner is uncertain about the needs, the team needs to factor that uncertainty into their estimate. Overcoming these problems: A good remedy to these first two problems is to ask team members, “What percentage of the solution do we really see?” If they tell you a really high number, push back to see if they have reason to feel that confident. 3. Estimating a best-case scenario. Some teams often unknowingly estimate the best case for doing work. They assume the product owner will immediately answer questions, that all inputs will be ready when needed, and they’ll encounter no problems. This is rarely (if ever) the case. Overcoming this problem: A good approach is to ask the estimators what has to happen for the estimate to be accurate. Listen for a reply that includes a list of risky assumptions: the hardware has to be here on time, the other team needs to deliver their component by Wednesday, or the vendor’s new library works as advertised. If you hear things like this, you’d be wise to ask the team if they really want to provide an estimate based on all those situations happening favorably. 4. Multitasking is not considered. Team members are rarely allowed to focus all their attention on one project or feature. They’re often told to maintain the old system while building the new. Or they’re helping to finish an item from last sprint while starting on a new item. It takes time for our brains to switch from one project to another. When this factor is ignored, work is usually underestimated. 5. They aren’t including time to iterate. Feedback is essential. Agile teams acknowledge that—but then often fail to include time in their estimates for acting on the feedback. For example, when a developer says something will take eight hours, they often mean eight hours until the first demo to users. The time to actually do the demo (and incorporate suggestions from it) is often not included—but should be. 6. Not all work is included. Teams often habitually overlook certain types of work. One team might forget to include database changes in their estimates. Another might fail to include changes to reports. Yet another may forget to account for meetings in their estimates. These blind spots can add up. 7. Assuming they’ll be more productive than is realistic. I think this is something most of us suffer from. I start the day ambitiously planning to get 8 hours of work done, and I end the day having had perhaps five productive hours. Overcoming these problems. These last four items all involve overlooking something that will affect the effort to complete the work. The best solution is to ask the team if they’ve considered multitasking, included time to iterate, overlooked any type of work, or based their estimates on aggressive productivity. Many teams will create a checklist with these items and more such as “Have you considered the impact on reporting?” Teams underestimate for a variety of reasons. You may not be able to correct each, but you can certainly take strides to reduce how much and how often your team underestimates. And providing better estimates will help you succeed with agile, Mike 1140 US Hwy 287, Suite 400-108 Broomfield, CO 80020.
Blogging from the Dashboard
On the dashboard, you have everything you need to manage your blog in one place. You can create new posts, assign categories, adjust SEO and more. Click Create New Post to get started writing, adding images and formatting your post.
Blogging from the mobile app
Write posts, reply to comments, and manage your blog all on the go. Download the Wix Owner App from the dashboard to get started.
Blogging from your published site
Did you know that you can blog right from your published website? Once you publish your site, go to your website’s URL and log in to your site with your Wix account. There you can write and edit posts, manage comments, pin posts and more. Just click on the 3 dot icon ( ⠇) to see all the things you can do.