WARNING: The following post talks about “commitments” and “planning” if your agile worldview finds these terms dangerous and unsafe, continue at your own risk. What is Commitment Driven Planning? Commitment Driven Planning (sometimes called Capacity Driven Planning) is a technique that lets a team determine how much work to bring into the sprint based on how much time they have to do said work. What do I need for Commitment Driven Planning?
Setup For this retrospective you’ll need sharpies, post-it notes and a wall, window or whiteboard on which they can be stuck. Setting Expectations At the heart of this retrospective exercise is defining expectations for yourself and your teammates. Start by explaining that on most teams, there are varying expectations. Some people expect different things from different people and from different roles. The exercise as described below is focused on a Scrum team, but the questions could be adapted for any team.
Physical Boards Please I recently started working with a team who had been introduced to scrum as part of their organization’s adoption of agile. Their only experience with scrum was through the lens of a popular agile project management tool that rhymes with alley, as in “After using this software I want to vomit in an alley”. When they had the chance to use a physical board, they jumped on it.
When estimating a project using the Planning Poker method, many developers like to use a baseline estimate for a given task. For example, many developers use CRUD, the creating, displaying, editing and deleting of a Model as their baseline estimate. Once they’ve got their baseline in mind, it makes it easier to estimate other stories that are more domain specific, or so it seems. Baseline Estimates are Broken When you’re using a task like CRUD as a baseline for your estimations, you can easily skew the estimations of the other stories in the project.
Estimating stories for an upcoming project is one of the more difficult tasks that agile teams have to perform. It’s never easy to determine how difficult it will be to implement a particular feature, especially when you’ve got different personalities, goals, and levels or experience in the same room. Unfortunately this all leads to people coming up with excuses and roadblocks which lead to inaccurate estimates. I’ve identified seven problems pitfalls of the agile estimation process that I’m sure many other teams have experienced: