The popularity of Agile processes is increasing lately in the delivery of IT projects. Among many Agile Processes Scrum process framework stands apart, which is evident by 94% respondents to State of Scrum survey 2017-18 said they use Scrum in their Agile Practices #1. This article explains the process of planning a software release, monitoring its progress through execution and possible controlling measures required to be taken when needed.
While implementing Scrum process frameworks typically all the planning is not done at once, rather it occurs at fixed intervals. This fragmented planning gives better control over the project execution and serves to incorporate corrective actions. Availability of historic data plays an important role in the whole process.
Initially in the process Product Owner discusses the high-level scope of release with scrum team. Next step is team decomposes this scope in artefacts called as Epics. Epics are defined as a group of work items by functionality. At this moment, Product Owner gets back to team with prioritization of Epics. The range of prioritization techniques are available at disposal to be used for requirement prioritization. This includes MoSCoW method, Kano Model, Business Value Bases prioritization, relative weighting priority technique, Walking Skeleton, etc. One of the prioritization model, MosCoW method is explained below.
MoSCoW method: MoSCoW method is one of the prioritization technique used in managing requirements. It, when used, consists of dividing requirements in 4 categories, Must have, Should have, Could have, Won’t have. Must have requirements are critical to be delivered in given release time, to release to be called as a success. Should have are requirements which, are important but not necessary to product release. Difference between must have requirement and could have one is time box. Should have requirements are as important as Must have ones, however not critical in the time line, as there may be a workaround, alternate paths are available. Could have requirements are mostly stretched goals, or requirements which fall into the improved user experience, at minimum possible cost. Won’t have requirements are the ones, on which all stakeholders agree that those have lowest ROI (Return on Investment), or not have a value from customer’s perspective at that moment time.
Once prioritization of Epics is clear to the team, the team works on estimating Epics at a high level. This is one of the reasons why the entire team needs to be involved in release planning exercise. While in the process of estimating Epics, interdependencies among Epics are mapped. This helps the team to generate an overall picture of the order of execution, dependencies. This data then goes through normalization based on the priority of Epics. High priority Epics are ordered first for early completion, other enable
Epics which catalyze the process of completion of these are scheduled appropriately. Across team, dependencies are marked clearly, and dependent teams are made aware of them. There are multiple varied techniques available for collaborating among multiple agile teams, scaling agile techniques is out of the scope of this discussion. This first pass through Epics ends when all Epics get estimated at a high level, and all dependencies are highlighted and planned for resolution.
Next pass through back-log (at this moment is set of these Epics) is aimed towards deciding and depicting milestones of progress. Important data to contribute to this is team velocity. Velocity is defined as the quantum of work delivered by the team in each fix time interval called sprint, measured by units of estimation. For example, if the unit of estimation is Story Points, velocity is a number of story points delivered by the team in each sprint. So, based on the velocity of the team, and considering first pass output of backlog, the team creates milestones (Based on Epic Completion) which will act as progress indicator through execution. This completes release planning for the team. The outcome of release plan is high level estimated Epics with predicted time for completion associated with each of them. This gives confidence to Product Owner about the realization of product development plan in near-term, and it becomes easy to Product Owner to prepare for customer engagement appropriately.
Below is table#1 that gives the synopsis of the release plan for a team
Monitoring progress towards release predictability.
After above tables are made, team proceeds through execution of sprint. While progressing project through sprints, scrum master updates information radiators, also updates tables, especially table#2 above to compare the planned execution of scope against actual execution.
If we look at above Table#3: Sprint Schedule during release execution, it has gathered data at end of Sprint #1 and data points to the fact that Story Points delivered at end of Sprint #1 is lesser than those of planed. At this moment, team discusses this issue in retrospective to find out the reason behind it. If corrections are beyond the control of team, product management is involved to take necessary corrective and preventive action. And progress towards release is tracked periodically using this mechanism.
References
#1: State of Scrum survey report: https://www.scrumalliance.org/why-scrum/state-of-scrum-report/2018-state-of-scrum
