Agile Practices for Project Management encourage effective and thorough planning. It enables you to identify and prioritize the features in your backlog by developing what is more important and of high value. When the essential features are done, the teams can easily work on the remaining tasks leaving room for improvement. Frequent integration and verification keep the team focused and managing the release simple.

As the release delivery date approaches, everyone in your team including business and management gets curious about it. There are multiple reasons behind such an interest. Some of the common reasons behind this curiosity are to make sure that we are fulfilling our promises with the customers, or the features should be ready before a public event which could be a good opportunity for sales, or release impacting other teams targets.

Releases are effectively managed if intermediate deliveries are launched during the project so we do not have to wait for the final delivery at the end of a project.

1. Prerequisites to Successful Release Plan

To create a successful Release Plan the following have to be available:

• A prioritized and estimated Scrum Product Backlog at least for a minimum viable product
• All members have an understanding of the purpose of the release
• The (estimated) velocity of the Scrum Team to avoid an unrealistic goal
• Defined criteria of satisfaction (release goals meet schedule, scope, resources)

2. Define Criteria to deliver a release

Release criteria depend on the product and the structure of the organization. Some basic rules for ensuring successful release are:

• All high severity bugs closed or deferred
• Release notes with a complete list of fixes/enhancements
• Test lead signs-off for the readiness of release

3. Create a Release Plan

Realistically speaking, a Release plan cannot be a static plan. Even after release contents are final, some changes are expected based on new knowledge or information revealed during development. Make sure that the Release Plan is updated at regular intervals.

• In release planning sessions, participants are not only from the development team.
• IT and management should sign off initially. To realize the complexity of solution designs before they start spending money and time, it is better to involve operations and appropriate management staff.
• Ensure that release management best practices are followed, system administrator and testing lead should be involved.
• To ensure continuous release tracking a Release Manager should be allocated, who has a complete list of release features and must understand deployment process. This role is essential to evaluate an issue as soon it rises and chase it to sign off for a successful release.
• The ultimate goal of any release is to satisfy the Customer. To close the loop of development, operations, a representative of the customer should be present to highlight any issue from the customer’s point of view. In agile teams, Product Owner may need to play both roles, if the customer is not available.

4. Monitor Release Progress

Some challenges that the team generally encounter and can be easily resolved if:

• • The product owner/manager defines features by priority in the Product Backlog and is able to revisit priority on the release board.
    • Development Team and Product Manager work together to define the priority of items for each release. It is possible that a feature has the highest priority in a release but its priority ranking in the backlog was not that high. In such case, Yodiz release board helps you categorize your release contents.
      • Add Items directly from the Backlog
      • Associate an item with multiple sprints
      • Create a User Story or Issue directly from the Release Board
  • To prioritize your release items without impacting their respective backlog number and star priority. On the sorting filter, select “sequence” option. If you rearrange release items according to your release priorities, Yodiz will remember release items sequence order that you can also revisit anytime later by selecting the same project and release.

• Development team needs to know, when to start working on a particular feature and when they can proceed to the next feature. Product Manager should be responsible for answering project contextual questions and Scrum Master helps the team to track the progress of items which are not in the hands of the development team.
• Team Lead respects the team and estimates on the amount of work that can be delivered and how much work is needed for the new features delivery.
• Scrum Master/Team Lead makes sure that the team progress is visible and transparent to all stakeholders
• Depending on the type of project (feature- or data-driven) the release plan can be created in two ways:
  • If the project is feature-driven, the sum of all features within a release can be divided by the expected velocity. This will result in the number of sprints needed to complete the requested functionality.
  • If the project is data-driven we can simply multiply the velocity by the number of Sprints and we’ll get the total work that can be completed within the given timeline.

Define personalized release workflow according to your organizations’ deployment and quality processes and follow progress using customized release board.

5. Succeed by managing DevOps Wisely

The primary purpose of DevOps is to automate the delivery process in a way that developers get immediate feedback as they commit changes to the shared repository. Development teams integrate their code on commit, so they can address a conflict as soon it arises.

5.1 Trunk and Feature Branches

DevOps and other technologies have made it easier for engineers to deploy new builds several times a day, but it is not always easy to track – when and what changes are shipped. If changes cannot be tracked properly in the code, IT and Operations team face difficulties in troubleshooting. For successful delivery and troubleshooting:

• Release work should be done in trunk mainly.
• Create Feature branches for a feature prototyping, where the owner of the branch is responsible to merge it in the trunk. This ultimately will help in avoiding multiple Pull Requests in trunk.
• Merge feature branches in trunk to perform regression testing.
• Create a release candidate branch prior to production where access to commit is limited to avoid unneeded hassle.
• After successful release testing, this release branch should be locked down and kept locked to handle a situation where a bug found in production needs to be fixed as soon possible.

5.2 Keep one Pull Request for the same logical change

In cases where you can not avoid additional changes after the Pull Request has been merged, try to group them into a single unit of change by using Yodiz Work Item reference.

Under Yodiz work item Commit Log section, you can see the updates. Using pull requests to change the status of reference work item updates people who are following that Yodiz work item and they get notified when the status of such item changes.

Use DevOps and integrate Yodiz with code-commit tools and send pull requests to track code changes. Check out GIT hook integration.

Yodiz is an innovation leader in Agile Project Management tools. We have customers from 60+ countries who get benefit of using seamless experience of agile practices without worrying about setup and administration settings.
If you would like to talk with Yodiz to see how you can benefit from an agile management tool, then contact us and we will arrange a meeting for you with one of our experts.

Contact us