To have a release you must have a start and end date, a set of work to be accomplished and a customer sign off. Why plan for this - reduce the time of meetings by producing rapid estimates of the work to be done. TRUST YOUR GUT!! This is not about being precise, but accurate. It’s about close enough to best estimate your release. In many ways this secures funding to move forward with ideas and solutions to determine whether we are going to get the right level of return or not.
Timebox
One of the true keys to the value and efficiency around release planning. TIMEBOX your planning sessions. There should be some acknowledgement from a Product Owner as to when backlog items would be desirable in a timeframe and a proposed go to market strategy. If this doesn’t exist at a high level at this point, your product may be evolving so quickly that we need to get a picture of what is most important now so you can capitalize on small iterations and the feedback gained from them.
No, it absolutely should not take all day to plan for a release. PLEASE plan for an hour and at most two. Preparation that goes into this session with the entire team is crucial because you don’t want a team of highly paid developers, testers, architects, DBA’s and others sitting around while you are typing into the computer what they are saying or what the Product Owner is explaining. There needs to be enough information to move to the next step. This is the beauty of Just in Time documentation which helps us have an idea of what ideas are being percolated to move forward with. Having the right people for the right discussions at the right time is crucial.
Understanding the Work to Be Done
Whether they are called use cases, epics, user stories, tasks, subtasks, defects, bugs or anything else, there needs to be an understanding of what work is being looked at for the potential release timeframe. These bold questions below will help the conversation move forward to know what there is to potentially be worked on in the near future.
Who is the target stakeholder (internal or external)....is this a member of leadership, a team member or a consumer / customer?
What is the problem to solve?
Why do we want to solve it?
So here’s what a common template looks like to address these questions:
As a <user> I would like to <do this> so that I receive <desired benefits>.
Example: As a trainer, I would like total registrations to be visible by session so that I know when to take other actions to ensure those training sessions don’t need to be cancelled.
When is when we discuss acceptance criteria. What needs to be possible or completed in order to claim your definition of done. This is a product of a mature backlog that will then become a product of a successful sprint and sprint planning
At the very minimum, a statement of requirement from the user’s perspective should be able to be looked at and understood in some context within a short period of time that sparks a discussion on what else is needed. If you are spending 5-15 minutes per item at this stage discussing each item, you are spending time on items that aren’t even baked yet. It is enough time to get a general idea so you can move forward based on information understood. Too often we spend hours at this level and then don’t end up implementing a large portion of features that get elaborated to the nth degree. Do not fall into the trap of over-analyzing everything at this point.
Velocity and Estimation
When it comes to a teams estimation, the use of velocity is critical to the forecast for future releases. This is not a scientific formula, nor is it something that can be compared between teams. This is TEAM SPECIFIC. Senior engineers vs. junior engineers; mature vs. new scrum masters; Seasoned product owners vs. one new to the job; and teams getting used to agile and scrum that have not truly become self-organizing yet. Regardless of what estimation technique if utilized, identifying estimates and dependencies are significant takeaways from a successful Release Planning session. It allows Product Owners and organizations to plan potential work based on the velocity of teams.
Let's explore a few team examples of release planning...
Performing Teams
When a mature team participates in release planning, you notice several things:
The team has a handsomely groomed backlog
The team, ScrumMaster and Product Owner know the drill… as in, they should be able to go through the process in relatively short period of time. Perhaps less than an hour.
The Product Owner is able to convey results of the release planning to stakeholders efficiently and effectively.
A little bit of advice with teams that are finely tuned. Don’t try to over manage them. When it is working, let them be Agile and you will get the short-term and long-term predictability out of them. If you try to over engineer management or ever ScrumMaster involvement with them, you are doing them a great disservice that doesn’t allow them to become self-organizing. When in doubt, observe what is going on and don’t be the Scrum Police… back off and let them learn!
Evolving Teams
This is a delicate dance to do with a team newly employing the agile mindset. Disorganization among backlog items and variance in priority may prolong the planning session. This may also create a concern from stakeholders about the validity of the planned release process and delivery date (definition of done).
If the team is too fixated on a tool to review their potential items for a release timeframe, this can also prolong their planning process. Tools, although well intentioned do not equate to the successful launch of an release planning process. When in doubt, pull out index cards and sticky notes. It seems very rudimentary, but the simplicity of moving items around quickly, labeling them with markers or adding new items being missed with another card allows the transparency to start happening. One team recently found the clunkiness of their backlog organization in their tool of choice made their release planning very difficult. They dismissed and reconvened with the backlog items and user stories printed on cards and were then able to size them and get them organized into preliminary timeframes and sprints in less than an hour. More than 90% of what they needed came out of that hour of time devoid of technology.
Take a look at this team doing a release planning session as they are evolving their process…
Multiple Team Deployment
With larger implementations, the need for organization is heavily apparent. Pre-planning becomes crucial for any type of Release Planning to be effective. The release planning death by meetings needs to be avoided at all costs. Input is going to be crucial for multiple teams to understand not only the size of their potential work but also the level of interdependencies that exist with their work. A team earlier this year was encouraged to complete a release planning session for roughly what they believed would be a quarter worth of work. After almost 500 items had been recorded for the upcoming quarter. Preparation for the session first involved securing a room large enough to have everyone there. Next it was getting each of the respective Product Owners and ScrumMasters to get the backlog items exported and printed off onto card sized pieces of paper. Making sure that markers, sticky notes and other office supplies needed to identify any unknown items was also necessary. Hours of preparation helped the session be more streamlined and done in less than an hour. Sizing or estimation occurred with efficiency and then internal and external dependencies were also understood.
The key here is organization and keeping the movement of items as fluid as possible. After sizing and dependencies were identified, the Product Owners were then able to start building out a tentative release plan based on the sprints that would be involved. Understanding the cadence of teams becomes extremely important in this stage of the process.
Make sure you utilize Release Planning for the success of your organization. Make it effective, get the right people involved and happy planning, Agilists!