Share This Page


Share This Page


Often, many well-planned projects go through a phase where the customers’ requirements change, or the level of expected defects moves outside of the forecasted threshold. Project planning tools remain the ideal way of planning, re-planning and measuring dependencies, team capacity, holidays however in the ecosystem of a medium to large program, new requirements can hit the schedule at any milestone during project.

Project management methodologies have been evolving over time and improving the delivery capabilities of teams by using approaches such as Agile/ Sprint that do not require full reliance on the waterfall models. It is not just true for Cloud projects where deployment time is short; this is very apt for on-premise projects as well, as the intention is to plan and deploy changes in the product.

This article is going to shed light on a real time example on how Microsoft’s ‘sprint planning’ template helped immensely in re-thinking the approach of delivery during a project execution phase. The project build phase was completed as per Microsoft’s project plan, which captured all deliverables, start/end dates, dependencies and key milestones. There were scheduled sessions with the customer every month to replay what was to be built before the commencement of the two testing phases (system integration testing and user acceptance testing). The point to note was the solution reviews and testing were limited to a core set of customer stakeholders who helped in the design sessions during the project initiation phase. As we started interacting with the customer's global stakeholders during phase testing level 2 and 3, the number of changes requested significantly increased, which made it difficult to accommodate the bug fixes, as all the milestones were tightly integrated with the project closure.

The icing on the cake - the go live window was restricted as this program was closely tied with another one, which would have had a huge impact if delays had arisen. This would have meant a high cost of team retention and an impact on other programs - a situation of chaos.

We obviously could not have dropped new changes as we needed to ensure the solution that was built was fit for the customer’s needs; hence we introduced a Release Plan-based approach to help schedule the deployments in a two-week window. The next action was the choice of the tool, and this is where the Microsoft Project Plan – Sprint template came to rescue to avoid – Plan, Re-plan, Re-plan …

New Sprints Project

Approach: Multiple workshops were held to collect all the changes required to solution (defect fixes, configuration change, new enhancements), which were put together in one sheet. The next step was to identify the prioritization (must have, nice to have and post go live) to brace the inflow of customer needs at a crucial juncture of the project. We categorized them further by the exact ‘month’ window to ensure how we staff the capacity of the team to cater to upcoming milestones.

To get started, we created new sprints in the Microsoft project plan that defined upcoming release windows for code build, test and production deployment.

Manage Sprint

While the Microsoft project provides you with the standard planning sheets to input all planned tasks, there are some additional fields that can be added as ‘custom’ fields in your plan. Example:

Sprint Planning Sheet

The sprint column plays an instrumental role to help select the window for a task completion and deployment. To ensure that the release window tasks are achievable, it is crucial to maintain the resource levelling in the team planning tab. Unless necessary, you do not need to use ‘Auto levelling.’ It is best to keep track of every item that a resource may be working in within the next 2 weeks and hold a daily stand up meeting – inviting various teams in 15-20 min interval windows to avoid wasting time for all resources. It is important to keep a check on dependencies as it is one of the areas where work done in isolation can impact another functionality in a fast-paced release window approach. Hence, a team catch-up to review the dependencies on the task is necessary on an alternate day basis.

Team Planner View

The sprint planning board – helps you keep track of the task completion and can be used for executive reporting as well on the progress of deployment. It is always a good idea to freeze a code deployment date in a release cycle so that all users can be informed the downtime window of the solution and can be made aware on what to expect post the release deployment.

File New Task Sprint

In the release-based approach, communication is very crucial to make the approach work. This is not limited to team communications – the release coordinator should work with customer stakeholders, experts for regression testing, change management team and the infrastructure team to plan mass deployments. It can be a bit of challenge to start with if the cross-stream interaction is limited. However, it picks up pace as you start to make progress. It is important to keep track of backlogs as there would be several situations when an item cannot be completed for a release and is required to be added to the next release sprint. All teams participating in the daily calls should ensure the correct estimation, prioritization and testing time to avoid having unhappy customers.

To conclude, here are some pointers for a sprint-based template release plan approach:

  1. Collate all open tasks including past deliverables, changes, enhancements and defect fixes
  2. Create a planning sheet with correct WBS
  3. Update prioritization for each task and define dependencies
  4. Review resource capacity and keep some room for over-allocation as some tasks may finish early, while the others may get delayed
  5. Maintain a health check of the release plan and conduct daily release meetings
  6. Communicate with the change management team to inform the end users on expected release deployment and its contents – it is good to give sight to upcoming release windows and critical items that are planned for deployment
  7. Maintain a backlog by using an additional field for ‘baseline sprint’ so you can keep track of items that may be slipping and take necessary measures to gain control

Happy planning!


About the Author

Shantanu Kumar
Senior Project Manager

Shantanu has over 13 years of experience and 6+ years in various project management roles in SAP and Oracle. He brings diverse and extensive IT Program expertise in ERP implementation, support and transformation projects including Cloud and on premise across India, North America and United Kingdom.

Other Stories by the Author

Let's Talk About Your Needs

Thank you for your submission. We'll be in touch.