Tharaka's Blog

Agile Release Planning

Posted in Project Management by Tharaka de Alwis on November 29, 2009

Companies that do not follow Agile processes tend not to do any release planning or they simply used to do releases for all iterations. Both of these approaches results in unfinished projects or products with incomplete features that lacks competitive edge and the due quality.  Based on new decisions of stake holders’, teams add new features thinking it was the agile way of doing releases. But they end up in nowhere.

What these projects lacked was the longer vision/road map where they would go with the development of the software.  Agile Release planning has being the practice of modern era PMs. The main goal of agile release planning is nothing but to “add or improve software delivery”. With stakeholders changing priorities of required features, leveraging agile mature practices will give your software the desired quality and competitive edge.

The following link contains the webcast  “Keys to Successful Release Planning: A Guide for Agile Teams” done by Ronica Roth (Agile Coach at Rally Software). She has over 15 years of Software Development experience and 6 years on Agile movement.  This link contains the PDF document of the presentation. This post is based on summary of this web cast and  I’ve summarized the important topic to share with you all.So this is how you do Agile release planning according to Ronica.

In Agile Release Planning there are five important steps

  1. Setup the vision – The Product owner of the software needs to communicate to Product vision to the team.
  2. Come up with product road map – comes with the vision of IT steering committee and domain experts to come up with Product back log. It contains all the features and bugs that need to be fixed to make the software ready to be shipped to the market. That will bring value to the customer.
  3. Release Plan – Breaking down Product back log features to N number of iterations. In Agile Scrum we call them sprints.
  4. Iteration – Within each iteration, the development team will gather requirements; do analysis, design, development and testing. Aim is to develop quality software that doesn’t break and add value to the customer.
  5. Daily reviews – Daily review meetings will be done to see how the iteration is going. With this we will know whether we are falling short of the iteration release beforehand.

For the Release planning steps

Fix a Meeting date to do the Release plan with the product owner and development teams.

The Product owner needs to give product pitch addressing on the desired schedule a date and scope. Scope of the product will come as the Product back log with priorities. Product Back Log will contain user stories with priorities and bugs to be fixed. The aim is to make sure the development team understand the scope of the product and see if the schedule is reasonable. Even through Agile, you cannot fix scope and schedule unless you are willing to add resources or throw out quality (simple rules in project management).

Each user story in product back log needs to be given a story point. Story points are derived from 3 parameters

  • Complexity – Complexity deals with moving parts. What interfaces are used. In simple terms, how difficult to find/recreate the scenario.
  • Effort – Effort is nothing but number lines of code & unit test cases might be required
  • Doubt – Doubt is based on uncertainties of technologies/domain knowledge that the team doesn’t have.

Base on these parameters each member in the team needs give story point for a user story. The webcast coach says her numbering is based on the Fibonacci numbering sequence. So the a story point will be one of the following: 1, 2, 3, 5, 8, 13, …

She says 13 is the maximum she would give for a user story in iteration. If it goes beyond that she would break the story into pieces.  To decide on this numbering two sizing approaches are used

  • Bucketed relative sizing
  • Planning Poker

Important thing to remember is that size is not equal to effort.

Based on previous Agile project deliveries team need to derive Velocity.

Velocity is derived in this manner: Velocity = Story Points/Iteration

If the team doesn’t know their Velocity, an assumption based range will be taken . For an example if the team does a maximum 20 story points within an iteration, velocity will be 20 and if the team does minimum of 15 story points per iteration, 15 will be velocity.  Over time the velocity will be stable for agile development team.

Iteration = Story Points/Velocity

With this we will know how many iteration it will take to deliver the software. Each iteration will be between 2/4 weeks.  With this you will be able come up with possible release date.

Delivery of the Plan should also address things such as risk, action items, issues and decisions made. The team needs to discuss these matters and have them addressed in the release plan.

Another important thing is to establish a good communication plan between stake holders and development teams. Ideally they all need to be in the same room. When teams are distributed over geographical locations, software like- Rally would help teams understand user stories, their goal, objectives and priorities. Rich conversation needs to be captured so that creative ideas of the development teams can be taken into consideration during the iteration.

There was a good story on how two development teams working in US and India with a 13 hour time zone difference and managed to do release planning within two days. It went like this

  1. On the first day morning in California, US, stake holders presented the product backlog with priorities. The Indian team stayed late to listen to the discussion and went back to sleep.
  2. US development team completed their story points and iteration discussion end of the day.
  3. Two member from the Indian development team woke up early in the next day and listened to the US development teams findings.
  4. Based on this, Indian team completed the release plan along with their concerns and shared it with US development team staying a little bit late (Indian time). Through discussion and collaboration both teams agreed on the release plan and went on with the execution.

Steps Preparation of the release plan –

  • Be prepared at least 2 hours before Release Plan meeting.
  • Review the Agenda goals
  • Gather data of previous releases, velocity chart, Calendar with company holidays, road map, risk and issues.
  • Preparation of the room – projector, beverages and sticky notes
  • For each topic have a time boxed approach to stop the team going to unnecessary implementation level details

Important things to remember

  • Stick to the plan but don’t marry the plan.
  • Plan but ready to re-plan when necessary (Part of being Agile)
  • There will be bumps on your way. So plan for unexpected bumps and be vigilant during the Iteration phase.
  • During the iterations, analyze your progress through burn down and burn up charts
  • End of an iteration – show the demo to stake holders. So you could re-plan the next iterations with stake holders desired product features.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: