Release Planning Meeting

Release Planning

Release Planning Meeting

Release planning is something that is mostly driven by the customer expectation especially if you talk about the Software Development companies. Release planning is an integral part of organizational planning especially the Product based organizations. Good organizations perform the Release Management for the Product or Portfolio in the same manner as they do for any Project. 

The meetings are almost the same like any other project management meeting with the only difference being that they are conducted at a much different (higher) level and with a much different (mostly top level management) audience. 

During my career, I got a chance to work as Owner/Manager of the Release Management Committee. My job included scheduling and conducting relevant meetings and other activities. The other members of the Release Management Committee included Senior Executives / Departmental Heads (aka EPIC members). 

One of the main activities of the Release Management Committee was the Release Planning Meeting. The organization had a very well defined Release Plan. There were 12 main releases, once a month. In addition to that there were 12 mini releases, almost mid-way through the main release. The concept was simple that all the work should be planned and released through these releases only and there will be no other release unless it is a fix related to “Production Issue”.

A Release Planning Meeting was regularly scheduled after every 2 weeks. Apart from the members of the RPC, the Project Managers/Project Coordinators and the Technical Leads were intended participants. The meeting format was simple, all the Competency Heads/RPC Members used to submit their respective list of User Stories before the start of the meeting. Apart from other brief information regarding the User Stories, two important attributes were mentioned in these lists; The expected team/teams to perform the work and the intended Release number. 

During the meeting, each Product Owner reads out his/her User Stories and relevant stakeholders can ask questions. The Project Manager of the relevant team then agrees to some release when his/her team will target to deliver the User Story based on their work queue. 

There was a parallel queue called the “Production Issues”, in which urgent production issues/User Stories were added and always had priority over the regular release items. 

At the end of the meeting, each EPIC member has some agreed timelines for all his/her stories and similarly each team has its prioritized backlog. 

The reason why I discussed the whole process was that I always feel that it was a very effective practice to plan items at product or portfolio level and at the same time letting the Project Managers and Teams to align their work and timelines. Once the EPIC members have these timelines, they can update their respective customers accordingly. 

One of the key indicators related to the Team Performance was the team RPC list and outstanding items. In review meetings, the Project Managers used to provide feedback and reasons regarding why any item was not completed as promised. Generally it is the Production Issue item that used to cause the delays. 

Share this post

Leave a Reply


%d bloggers like this: