Scrum like Waterfall, or how to manage team work to deliver software development projects on-time

Scrum Software Development case study: How to estimate delivery times and take ownership of results?

A client hired our dedicated software development team for a rather complex project that involved building a new sales platform for their financial products. They had already adhered to high standards in their processes and methodologies, gradually leaning toward agile methodologies.

Importantly, however, the previous stage of the project was completed in the waterfall model: we did not start from scratch but joined the client to work directly on the solution. This meant that the whole project team (ours and the client’s) had to smoothly transition to the scrum model. 

On our side, the software development team consisted of more than 20 people, mostly developers. However, to ensure the success of the project, we also had a group of business and system analysts, as well as testers. Not to mention a separate role, that of the Scrum Master, necessary on account of our team size and the complexity of the project. 

Importantly, our partner had one important requirement. Even though the stage where we entered was to be completed using agile methodologies and we did not agree on a specific delivery deadline, the client actually expected us to estimate deployment time soon after the launch of the project.

This is not a scrum standard, but thanks to a set of processes, standards and tools, you can actually estimate the deadline in agile projects quite accurately, without giving up on the advantages of agility for scrum software development.

Stages of building the target scrum model and software development project planning

Stage 1.0

We had to transition from a waterfall model at the start of the project, and our team thought that a complete rapid shift to scrum could be too risky. Set to work with more than 20 people to deploy the first standards and tools (such as Jira), we decided not to divide our team immediately and estimate the costs of successive functionalities/stories by mapping story points 1:1 to time units (hourly rate).

This is not a scrum standard, but the approach helped us start off smoothly on the project and educate the client’s team step by step on what the target story points should really look like. 

Not unlike the previous, waterfall stage, estimates were performed by experts. A group of leaders on our side provided successive estimates and the team went along with the tasks, confident in their accuracy. Another aspect that went beyond the textbook scrum model was the parallel launch of analysis sprints and developer sprints.

This had to do with the client’s request for a precise deployment deadline. To pull it off, we wanted to use the Fix Version Report tool, but before we could to do that, we had to estimate the cost of all backlog stories assigned to this particular stage at a very fine-grained level. 

The backlog building stage as such represented an important step in the context of the architecture and the bundling of stories into epics, versions, etc. We knew we had to think it through really well to facilitate future Jira data reporting (e.g. to enable a context-based choice of version or all stories related to integration contracts). 

The stage consisted of 3 sprints. 

Stage 2.0

At this stage, we slowly got closer to building the target scrum model for our project. We divided our team first into two and later into three scrum teams that would gradually increase their cooperation, communication and self-organisation. Each team had a group of developers and testers, while analysts joined them for particular sprints.

At the same time, we launched other scrum standards (initially focusing on scrum meetings) and started to count story points in accordance with the methodology (earlier training finally allowed us to detach them from time as a measure). The cost estimates were also calculated with the use of Scrum Poker, thus shifting the responsibility to each individual team member. 

As soon as we launched the scrum elements, we started to closely watch the burndown chart, our basic control tool for team work optimisation. And once the backlog analysis allowed us to estimate the costs of all stories, the Fix Version proved very useful. 

Capacity – the bedrock of developer team performance  

We knew that when it came to people and their availability, it was better to plan ahead. The first and basic method, of course, was to create a schedule of vacations/days off. We also employed a simple Excel sheet to visualise developer availability; after all, developers were the key experts in the team, always in the first line of fire, burning down story points.

Their presence informed all our decisions in terms of story point capacity in each sprint. Simple calculations based on the presence or absence of developers were a better predictor than any plans based on results achieved in earlier weeks.

Tools: how to monitor progress and time-manage a scrum software development project?

Tools: Sprint burndown chart

The benefits of using a sprint burndown chart:

• Monitoring sprint progress in real-time;
• Estimating how much work remains to be done;
• Detecting sprint problems early;
• Supporting communication within the team;
• Motivating the team;
• Supporting the optimisation of team work.

A sprint burndown chart is a tool that allows you to detect many irregularities in the project, starting from very basic errors such as the incorrect use of Jira. Much of the performance of developer work is lost due to simple oversight, such as, e.g. a failure to quickly move a Jira task on to the next person. 

The burndown chart will also let us know if our stories are too big. If a sprint story requires several or more than ten days, it should be cut up into smaller pieces.

If your scrum software development project is too long, testers won’t work optimally; usually, they should get down to testing on the second day of the sprint. Our recommendation would be to keep your stories down to fewer than 13 story points. 

Tools: Fix Version Report

The benefits of using the Fix Version Report:

• Tracking progress on product updates;
• Strategic control of the backlog (in agile projects, the backlog is alive, with new stories being added. Fix Version Report gives product owners a better picture of the whole process, alerting them if new updates delay deployment so that they can take appropriate measures and, e.g. trim the MVP to deliver it on time);
• Drafting accurate work schedules;
• Continually improving work processes;
• Coordinating actions (business-technology) to achieve goals.

In order to allay any doubts that we may have compromised project flexibility to set a deployment deadline, let us say that even though we started from 1100 story points, our final MVP already had as many as 1400. Scrum is not meant to lock down the backlog; thanks to the tools discussed above and others, it allows you to assess your actions and stay consistent, as well as clearly plan out your work and launch sprints according to a pre-established schedule. 

Want to know more about IT team management and scrum software development?