The release planning four letter word….
One of the most difficult answers to provide to someone at the outset of a project is when a project will be completed. First, the very definition of the term “completed” leaves a lot to be desired. Our basic Agile principles tell us that the project scope and delivery is directly tied to the direction and vision the customer or Product Owner has. If a Product Owner would rather spend three additional sprints to see some key functionality that was not initially scoped prior to launching the software, how does that dynamic play into the notion of release dates? Also, consider that often times this question arises in organizations that are new to Scrum and have not yet established a known velocity. While we can use any combination of techniques to estimate velocity on a team with no known history, this is purely expert guessing and lacks any rigorous approach to ensure accuracy.
The very fact that when a team has no history of working together (for new teams, or when significantly changing the team makeup) makes projections based on historical data less than optimal, both in terms of confidence and accuracy. The confidence factor is something that keeps the team engaged and working towards the goal. A team that lacks confidence that an estimate has been arrived at properly tends to feel stress, either self-imposed or implied, and this can have very negative consequences to productivity and quality. One of the principles of being a Scrum Master is to shield the team from outside influences that might seek to derail, disrupt or disturb the team. This also applies to anything that might hurt morale and confidence. Much like the concepts of instilling confidence in an end user of software, developers and other team members need constant reassurance that their time is being used most effectively, that their individual and team contributions are being noticed and valued, as well as the single concept that each individual on the team has some intrinsic notion of what represents a reasonable amount of work to accomplish in a given time frame. In fact, in Scrum, we leverage this instinct across groups to provide more accurate and binding estimates during our Sprint Planning meeting.
The most effective method I have found has been to educate the person asking for the delivery date on how difficult the estimation process is without having a quality Product Backlog and known team velocity, which are the initial states of most teams and organizations new to Scrum. I sometimes refer to the concepts surrounding “The Cone of Uncertainty”, or otherwise that farther out from the project completion date the estimation accuracy and thus the confidence of most involved in the project is fairly low, but as the work progresses over time towards the goal, the group, project and arrival date come into focus. This allows for the use of historical analysis based on actual team performance, which is the best indicator of future throughput. Simply put, when comparing a well-defined and scoped Product Backlog to a team’s known velocity, Release Planning is basic arithmetic.
I believe most of us that seek to put together some sort of estimate at the outset of projects, especially with new teams following a new process, need to ensure that a comprehensive understanding must exist relating to this initial uncertainty and that through our process of continual improvement, both the velocity of the team tends to pick up as time moves forward, as well as our confidence in determining the value of this four letter word…