I have tried a few different things, but here are the ideals that have worked best for me:
- Think of dev work as 'closed door' costs: how long would it take if she was never distracted by emails, meetings, phone calls, lunch, beer runs, etc.
- Identify, for your team, the ratio between 'closed door' costs and real life. Do your planning in 'closed door' (easier for devs to estimate) and use history to identify the ratio. This also allows you to try things out to lower the ratio (free soda/lunch delivery, email filters between 10am and 4pm, etc.)
- Consider sprints as having a full day for planning, stabilization, and review. So for a two week sprint, use Day 1 for planning, Day 9 for stabilization, and Day 10 for review/retrospective.
So if you have 5 developers working 8 hours a day for a two week sprint, and you figure out that your closed door/open door ratio is 1.5, you have 5.33 closed hours * 5 devs * 7 days = 186.6 hours of work you can plan for.
If you have a strong SCRUM master (or other process leader) and push your team to have a complete definition of 'Done' (i.e. documented, tested, buddy built, and integration tested), you won't need a stabilization day, but it takes some effort to get there.
The benefit of this blended process is that you can use the open/closed ratios to understand each developers work habits (some are great estimators and have a ratio of 1, some people are pessimistic about everything and might have a ratio under 1).