Estimates are the bane of software development. They are rarely 100% correct, but you can make better estimates if you follow these steps. SoftwareDevTools as usual sharing what we've learned in our Agile journey
Keep in mind that estimates are only one aspect of making your next software project successful from the start. You need to be fully aware of How to adopt Scrum in your team.
Without Further Ado
Get the whole team to learn what the user Stories are all about. It is very important that everybody in the team understands all the features that go into a Sprint. Clarify the requirements until everybody understands, in depth, what they are estimating.This will save you time down the line, and remember: In Agile, as in life, time is precious.
The team must include an active Product Owner, otherwise do not make with estimates.
The Product Owner needs to answer every question the team raises. If the team doesn’t raise any question, then you have a problem. Keep at it until everybody understands all the Stories in the same way.
Use Planning Poker to involve the whole team in making estimates. For distributed teams, you can use a tool like Scrum Poker for Confluence or Scrum Poker for Jira app, whatever tool you use. These integrations save a LOT of time.
Alternatively, have the team make three estimates for every Story: best case, worst case, and most likely case, in that order (i.e., ask for their most likely estimates last). You need to give people a chance to first be their usual optimistic (best case) or pessimistic (worst case) selves. Once they get this out of their system, they are in a better position to come up with a realistic most likely estimate. Once you have these numbers, you can calculate the ETA as,
(Best Case + 4 * Most Likely + Worst Case) / 6
Promote a participative culture in your team. Ask and encourage others to challenge estimates that seem out of range. Why is the estimate so high? Why so low? This discussion might uncover obstacles and opportunities that would normally go unnoticed. The Key Elements of an Agile culture might be helpful. As weel as establishing culture using the Prime Directive.
Keep cycling through the estimates until every single question has been answered and each estimate has been sanity-checked by the whole team. BTW, besides better estimates, this process really cements the team’s commitment to these estimates.
Calculate the team’s capacity per Sprint as:
Capacity = #team members * working hours * days in Sprint
It’s important to take into account vacations, holidays, personal time off, and anything else that may limit capacity (e.g., office move). And once you know the team’s Capacity, then you can figure out how much payload you can fit in a Sprint.
To learn from your estimation process, keep track of metrics, especially deviations. Once you have history from at least three Sprints, you can use these statistics to polish future estimates.
It is very, very important that this be a commitment-driven process. The Sprint goal must be crystal clear and the whole team must be on board with it. A committed team will make sure that Sprints are delivered as promised.
As your team gets better at making accurate estimates, they’d get better at making their next software project successful.
Original post by Julio Cesar Gonzalez on Nearsoft Inc’s Blog.
Trying to improve your #Agile practices? OR are you getting started with Agile? Are you in a remote team? Check out our products for Agile teams at SoftwareDevTools. We focus on making agile ceremonies more effective and easier to adopt for remote teams.
Check out our Atlassian tools:
- Agile Retrospectives for Confluence
- Agile Retrospectives for Jira
- Scrum Poker for Confluence
- Scrum Poker for Jira
- Stand.bot for Stride: A bot to automate daily updates.
- And for Slack also!
Follow us on our networks:
Facebook: /SoftwareDevTools
YouTube:SoftwareDevTools
Twitter: @softwaredevtool
Email: [email protected]
And Subscribe to our blog below!