I'm a developer on a small-ish team. 1 DBA, 2 Senior Devs, 2 Juniors, and 1 QA (sometimes, most of the time we do our own QA). No PM at the moment. We do mostly maintenance/upgrades to a large legacy system right now, but will likely split the team soon so a group of us can focus on new product development.
We're a relatively new team that's been together for about 6 iterations now (3 months of 2 week iterations). Although we're using two week iterations, we're not down right time boxing. If a task is in progress, it stays in progress as it was already deemed the highest priority item. The iteration is more of a way of building in a time to retrospect, course correct, groom the backlog, and measure our capacity. It's Kanban with some ceremony stolen from Scrum.
So, this all works fine for this maintenance project, but with the new product development, we're going to have to really commit to getting the tasks done that we say we will. The problem is that the team is consistently overly optimistic during our planning session. We've never gotten all of our stories completed, regardless of the fact that we know exactly how much work we can do, on average.
We're able to consistently complete 13 stories in an iteration, but the team keeps insisting on scheduling 15-18. Any advice on how I can get them to understand the importance of scheduling to our capacity and committing to our stakeholders?
I'm sure someone will ask about story size/points. I don't quite trust scheduling to average points yet. The number of points completed in an iteration vary too wildly yet for scheduling purposes.