How we did SCRUM: adapting the framework to a real project

Every development team's worst nightmare is to dive into an unfamiliar subject area, estimate a half-baked idea and give a firm promise to deliver within a fixed deadline for a fixed price. In reality, giving a precise estimate of imprecise requirements is impossible. We took a different route, and here is how we adapted classic SCRUM to a real project: a game of poker in the office, discarded functionality, a "brutal editor" for the head teacher, giant drawings on the walls, a live feed instead of a dozen messengers, plus markers, sticky notes and dot voting.

Why SCRUM when the requirements are imprecise

The typical path in project management is to draw up the most detailed technical specification possible before development starts, and then implement all the functionality in one big chunk. But this "waterfall" approach carries other risks: the client sees the first result only at the very end of the project, and that result may turn out to be very far from the real business goals and user needs. Why take that risk if you can go about it in a completely different way?

When, while getting to know a project, you realise "we know that we don't know this" and even "we don't know where the boundaries of what we don't know are", SCRUM comes to the rescue.

The specifics of SCRUM can put off anyone who has never worked with the framework: at the start, the length of the road you will have to travel to get a working project that satisfies you 100% is still unknown. It is hard for the client — they cannot prepare a strategic development plan with reliable release dates. The unknown is frightening, especially when you have to pay for the journey right now.

But there are upsides too: at the start, the client does not have to describe every function and feature of a huge future system in painstaking detail. And they can change priorities at almost any moment and adjust to the competitive market outside.

SCRUM relies on the concept of small steps: release versions of working software regularly, as often and as early as possible. Each iteration is a micro-stage of development that is immediately tested in practice. This means that after the very first iteration the client receives genuinely useful functionality — small, perhaps, but working — puts it to use and gives feedback right away.

The important key decisions — what value to deliver to the business next — are made by the team before every new iteration, continuously. As a result, the system evolves along a critically optimal path until it fits the business as well as it possibly can. The client is part of the team here: both the contractor and the client are responsible for the success of development. They are on one team, not on opposite sides of the table.

The project: an automated system for the A+ Academy of Modern Education

We want to tell you about our path of adapting the classic SCRUM framework while working on an automated management system for the A+ Academy of Modern Education. It is a modern educational centre in Kyiv that includes a school, a kindergarten, an early development centre, music, dance and sports schools, art studios and a foreign language centre.

How the client and the contractor can start working with SCRUM

To work in an unfamiliar paradigm, the client sometimes has to change their habitual way of thinking and get into the same context as the contractor. That is why, before developing the system for the Academy, we organised a joint training session with the Scrum Ukraine team. Its main goals were: to get to know each other, get to grips with the terminology, practise all the methods in a playful format, model the core activities, work out where to start, assign roles and write down responsibilities.

Over three days of joint training we used the so-called helicopter view to sketch out the future system in broad strokes and captured it on a timeline in the form of a Project RoadMap.

Helicopter view — a general description or opinion of a situation, rather than a detailed oneDefinition of the term

The conclusions we drew after this stage

• Joint training helps change the mindset of both the client and the team.
• A Product RoadMap makes it possible to visualise the high-level development plan and roughly schedule releases. It is important to understand that this is a "living roadmap" that will change as new development details come to light.
• Agreement on the global rules of the game is needed up front: after every sprint the product owner receives value — a working system that should be put to use immediately, with feedback given afterwards.

The third point is mandatory; without it nothing will work. Because hopes of launching after some abstract full readiness at the finish line lead to disappointment on both sides:

• From the client's side: "This is what we asked for, but it is not what we need."
• From the contractor's side: "We did exactly what you asked for. And now your requirements sound completely different to us. We agree to redo everything, but at your expense. And in general there are so many changes that the rework will take another six months."

Step 1. Business analysis, the product backlog and user stories

We begin the development of any project with business analysis: we need to understand the specifics. Every company always has a lot of processes, and our task during the research is to find out how the participants in the system interact with each other before we build that system. After a round of problem interviews and processing the information we gathered, we obtained a description of the subject area in the form of usage examples.

Although SCRUM does not require a development specification, the fact that we had a ready description of the subject area turned out to be a big plus. That document became the basis of the product backlog — the foundation for starting SCRUM.

A product backlog is a list of requirements, stories and features ordered by importance. Everything starts from such a list. All the requirements in it are described in language the client understands. The items on this list are user stories. Our product backlog contained 203 stories, grouped into segments for convenience.

The conclusions we drew after this stage

• Our sprints would be two weeks long. Why? Short sprints are convenient: they allow the team to be as flexible as possible — ready to adjust plans often. A short sprint means a short feedback loop, and therefore frequent releases. Frequent releases = fast client feedback = less time spent working in the wrong direction = fast learning and improvement.
• Long sprints have their own advantages — less overhead such as sprint planning, demos and so on. But we chose short ones in order to stay flexible and take fewer risks.

Step 2. Sprint planning and the first value for the business

Our first piece of value for the business was the electronic gradebook. To most experienced developers this will look like a utopia: we had a blank sheet in front of us, not a single reference list, no user interface, no authorisation system, not a single business entity — and we were committing to deliver one of the most complex functions of the system.

Two things were essential for us: a formulated sprint goal and an approved sprint backlog. Our product owner always started sprint planning by describing what had to be done first — the most significant stories. After that the team estimated the effort for all the user stories, starting with the most important one. In the process the team had plenty of questions about how it all should work.

Sprint planning is a very important SCRUM activity. Everyone understands the responsibility of estimating correctly, because:

• it lets the business understand what functionality it can expect at the end of the sprint, and lets the team be predictable and stay "on the same page" with the client;
• the value of a half-implemented story is zero, so all the stories planned within a single sprint have to be finished;
• any changes to an estimate during a sprint are ignored.

The electronic gradebook after the first sprint

Simplifications and assumptions for the first sprint. The system had two users: the teacher and the parents; one class — 5"A"; the real class roster, entered manually straight through SQL queries; the real timetable for 5"A", created the same way by writing directly into the tables.

User story No. 1: the teacher logs into the system and enters grades for any subject on the class timetable for that day. A system with one simple but already working function. At the very first sprint demo the teacher told us what was convenient to use and what was not, so that in the following sprints the team could plan adjustments and deliver an updated tool.

The real value it delivers: digitised performance data for a real class, up-to-date grades, and the prospect of automatically preparing monthly, semester and quarterly reports.

User story No. 2: a weekly performance report emailed to parents.

The value it adds: keeping parents informed about current performance; teacher comments on homework; minimal but real analytics.

After a few sprints I decided that there was enough functionality for teachers to work with the electronic gradebook. So we put the development of that tool on pause and shifted the focus to the timetable builder. That is normal for SCRUM. I brought the development focus back to the electronic gradebook about ten sprints later, and, partly discarding the simplified functionality, we brought the gradebook to the state required for analysing yearly performance. That functionality was more necessary for us at the time. We had obtained enough value and switched active development to higher-priority parts of the system.Sviatoslav, Product owner

For reference: to lock down the final, ideal version we had to come back to the electronic gradebook over several sprints. The version of the gradebook that could already be shown to parents was ready after the 12th sprint.

Another vivid example of the iterative approach — the timetable builder

Before this, the Academy's timetable was put together by hand on glued-together A1 sheets of drawing paper: they drew it, highlighted it with coloured markers and taped the sheets together. It took the head teacher weeks and months.

The client received the first timetable builder two months after the project started. It was a "brutal editor" for a very advanced user. But it allowed us to enter the timetable for all the fifth-year classes and test the system on a real, live timetable. Reworking it into a "visual editor" took three sprints. The development focus switched several times, but by the start of the school year the client had a fully functional timetable builder.

The conclusions we drew after this stage

• Every sprint must have a clearly formulated goal.
• Simplifying functionality and then developing it further is normal. That is exactly what makes SCRUM good: there is no single right way to build a product. It is not a textbook with exercises and the correct answers at the back. You can always consider many alternatives and carry them out in different orders. If at the end of the sprint the client receives finished value they can work with, test and enter new data into, and it moves things forward towards the global final objective, then it is the right path.
• The core philosophy of SCRUM: do not chase beautiful code at the start; concentrate on giving the client a working tool. So you can live with errors along the way, but you have to understand that the best way to uncover those errors is to stop thinking about perfect code at the architecture and design level and first give the business a working prototype.
• It is important to make changes to user stories during discussions and to save all artefacts and attach them to the cards.

Estimating in story points: SCRUM poker

A team will always estimate a user story sensibly if certain conditions are met: the behaviour of the real user is described in detail, the boundaries of use and the assumptions are marked out, and the acceptance criteria are listed. In other words, the team understands "what" needs to be done and roughly assumes "how". Formulating acceptance criteria and boundaries of use matters because it gives the product owner and the team the same understanding of the scope of work for each story.

In SCRUM, stories are estimated not in hours or days but in story points. This is a mix of complexity, risk and effort the team has to spend to complete the story. For every team, 1 story point is an individual, empirical quantity, but every team member can feel it.

Note that the sequence of values on the cards is non-linear. For instance, there is nothing between 13 and 21. Why?

1. So that no false sense of precision appears. If a story is estimated at roughly 17 story points, there is no point discussing whether it should be 15, or 18, or 21. All we need to know is that the story is hard to estimate. So we assign it an approximate estimate of 21.
2. So that we do not overestimate our own capabilities. People tend to exaggerate their strengths, and the scale keeps you from getting the time and resource estimate badly wrong. Say the team agreed that 6 story points are enough for one of the tasks. But if there is no confidence that even 5 would do, it is better to pick 8. This makes it possible to set realistic deadlines the team will definitely meet.
3. So that a dialogue begins. The scale helps participants share their vision of how the story should be implemented, voice risks and reach consensus.

This is very important: every team member has to give an estimate. Why?

• To give a well-reasoned estimate, every participant has to understand perfectly what the story is about. By getting an estimate from every team member, we make sure everyone knows what is being discussed. This increases the likelihood of mutual help during the sprint. And most importantly, the most critical questions about the story surface as early as possible.
• Different perspectives on a problem lead to a wide spread of estimates. Such discrepancies are better discovered and discussed as early as possible. After the discussion comes a re-estimate and a vote. Usually a couple of estimation rounds is enough to clarify the main points and build a shared understanding.

A vivid case: the "Live feed"

A school management system generates many events of varying importance. For example, a pupil received a grade; there has been a substitution and biology with a different teacher will replace maths; an unfortunate incident involving a pupil occurred and the parents need to be informed immediately; a teacher wrote an important comment on a homework assignment.

Sending this data by standard means to messengers or email is inconvenient for users and, frankly, yesterday's approach. On top of that, a notification may concern several people at once: a teacher needs to tell parents that their child left the school grounds during a lesson. In the original document these rules filled ten pages.

When we discussed among the developers how much work the "Live feed" story would take, everyone said how many story points they thought it would need. It turned out that our views differed widely, and we paid attention to the extremes: why did one person estimate 50 while a colleague was confident it was 5 story points. That is how we immediately uncovered requirements that had gone unnoticed — spotted by the more cautious developer. On top of that, global tasks related to personalisation came to light. It is a great example of how a team can anticipate difficulties.

The conclusions we drew about the estimation method

• Yes, it is normal for QA and the UX designer to estimate a technical story as well.
• In the first sprints the team resists empirical story points, because estimating effort in hours and days is more familiar and "easier". While we were bedding in this estimation system we sometimes got things badly wrong, but later we determined the scope of tasks in story points very accurately.
• By the 2nd or 3rd sprint the team clearly understands how much 1 story point is.

Step 3. The daily SCRUM and the cross-functional team

The daily SCRUM meeting, or stand-up — and indeed the whole of SCRUM — is a story about effective communication that helps save the team time and effort. These are not just "meetings" and "talks". They do not eat into time that could be spent working; they help optimise effort. One of the principles of SCRUM says exactly that: "Individuals and interactions over processes and tools."

Each team member briefly reports, following a specially designed checklist, what they have done, what problems they ran into and what they will do next. Nobody is left alone with a problem; they get quick help to solve it in the most effective way. This way an engineer does not waste time on unsuccessful attempts that might have to be redone from scratch, and thus saves the whole team's resources.

Cross-functionality: the team is ready to handle any task involved in launching the product

When forming the team, we selected T-shaped specialists who know their way around many areas and are experts in at least one. Thanks to this versatility, all the engineers know the system well enough. Everyone's experience is valuable when searching for the most effective solution: one person may lack the experience needed for a specific task, but their colleagues most likely have it. The same applies on the client's side — one person may not know certain details, but another one does.

To make my team even more self-organised, I documented every sprint using a strictly defined template: the number, the sprint goal, the sprint backlog with an estimate for each story, the team composition, the deadlines, the time of the daily meetings, the organisational events. It is all laid out in such detail so that, by moving steadily, step by step, we are guaranteed to have finished value ready for the client by the end of the sprint. So that the client is satisfied and starts using it in their business immediately.Maiia Sokolska, Scrum Master

The conclusions we consider important for the sprint running stage

• A team will become self-organised, autonomous, self-motivated and highly productive if nobody interferes with its work during the sprint.
• The emphasis has to shift: the daily SCRUM is needed for communication, not for administration.
• Every subsequent sprint must take the experience of the previous ones into account.

Steps 4 and 5. The results demo and the retrospective

How we ran the demonstration of results

The developers take turns demonstrating the new functionality live on real data. The focus is on what we did, not on how we did it. In general, we constantly strive to keep our demos business-oriented, with no mention of technical details.

Here the sprint goal comes to the fore again. Specially invited teachers and head teachers who had not been at the planning session often attended our demos. They knew about the product only in general terms. We always welcomed clients trying something out in the system themselves after every story we demonstrated. That way the end user checks every item of the acceptance criteria. They say what works for them and what does not, and which aspects could be improved. And so it goes for every user story planned for that sprint.

The conclusions we drew about the method of demonstrating results

• The mandatory line-up for a demo: the product owner, the scrum master, the client's representatives, the end users who will work with the tool, and the team.
• Before each demonstration you should read out the corresponding user story to give everyone the context.
• It is useful to run the demonstration on the production system with real data and real users who already work in the system. This approach is possible once the system is in alpha testing.
• It is important not to spend a lot of time preparing the demo: we never created a flashy presentation and concentrated solely on demonstrating genuinely working code and collecting feedback.
• There is no need to show a pile of minor bug fixes and trivial features. You can mention them, but demonstrating them is not worth it, because it takes a lot of time and reduces attention to more important stories.

How we adapted and ran the retrospective

For us the retrospective is an important event held immediately after the sprint demo. Retrospectives are useful, especially when something is going wrong. Without them it may turn out that the team is making the same mistakes again and again.

The most frequent trap is when the team's actual productivity differs greatly from the forecast. Actual productivity is calculated on the basis of the initial estimate of each story. And when halfway through the sprint we realise that a story estimated at 5 story points is taking as long as a 13-story-point task usually does and is far from finished — and if it is also a blocking story, others cannot be started because the problematic one is not ready. When the sprint goals are at risk, a retrospective is inevitable.

Our retrospectives have an absolutely clear structure and set of goals. The team gathers together, the Scrum Master reads out the sprint backlog and asks every team member to speak up and assess the sprint's outcome from their point of view. Everyone says what went well, what went wrong and — most importantly — why. What to keep doing and what to drop. And nobody interrupts them. They write their conclusions on a sticky note and place it in one of the columns:

• good;
• could have been better;
• needs fixing.

Once the team has finished brainstorming all the problem notes, I run "dot voting": every team member has three votes — three marker dots on the notes. They can give all their votes to a single problem or distribute them differently. Based on this team vote we choose 2–3 improvements to focus on in the next sprint. And at the start of the next retrospective we check how we did. A kind of "homework check".Pavlo Kamyshov, Agile Coach

An example of our improvements from one of the retrospectives

• When a developer builds the front-end and we start implementing it, the designers must be available 100% of the time.
• Discuss the inclusion of methodology hours with the product owner.
• When it comes to ergonomics, it is important to get as much documentation as possible.
• Technical debt should not be allowed to accumulate. Agree with the product owner to allocate 10% to technical stories.
• There should be a specialist who resolves technical questions as they arise.
• Sprint grooming must be held before every sprint planning session.

Yes, SCRUM demands active, engaged work from every team member. The activities — grooming, planning, the daily SCRUM — took about 12% of our billable time. It is a kind of price paid for transparency, predictability and lower risk.

One week of work can save one hour of planning.Pavlo Kamyshov, Agile Coach of Scrum Ukraine

12% is a lot, but it is worth it: in classic "waterfall" the price of using the methodology is a separate project manager role. On average in our market segment, about 15% of the development cost goes on management.

The conclusions we drew about the method of running retrospectives

• For us the retrospective is the second most important event in SCRUM after sprint planning.
• Every team member speaks, so that everyone shares the same information space.
• Every change has its price. You have to agree with the product owner to include technical stories and methodology hours in the sprint backlog.
• Methodology hours are paid for by the client.

Step 6. Product backlog refinement, or grooming

Many colleagues familiar with the specifics of IT will be sceptical: how can everything be so clear to the team during sprint planning that it is ready to estimate every user story? True enough, without preparation you will not achieve that kind of coordination.

For it to work, there is a dedicated SCRUM activity: product backlog refinement. To run it you need to ask the product owner for a planning horizon — an outline of which stories could be candidates for the upcoming sprint. If some of them require deeper study or special competencies the team does not have, a meeting is scheduled — grooming, or pre-planning.

Our product owner was very competent, so we always had a sufficient horizon of visibility into how the system would evolve, and we held refinement sessions regularly. After all, transparency is one of the foundational principles of SCRUM.

The conclusions we drew about the method of running refinement

• It is an important event that helps clarify what we do not know and which competencies we lack. For instance, we once decided to bring in an external developer as a consultant on specific questions we had no experience of solving at the time.
• These discussions were highly effective for us: we considered a multitude of alternatives and options, which kept the problem in our heads, and by sprint planning the hardest story had already been broken down in detail.
• Problems that seem complex and unsolvable find clear solutions. Sometimes it is enough simply to buy a library rather than develop a complicated part yourself.

Experience shows that 10% is a sensible average of the overall time incurred on a Sprint to spend on Product Backlog refinement.Verheyen, Gunther. Scrum — A Pocket Guide

Failures: three moments where we would have laid down a safety net

Yes, we are genuinely enthusiastic about developing with the SCRUM methodology, but that does not mean everything went smoothly. Here are three moments where we would have laid down a safety net had we known in advance that things would go exactly this way.

1. Working by familiar routines. At one of the retrospectives we analysed in detail the reason for an anomalous deviation in the team's "actual productivity" across all the stories involving designers. Actual productivity is usually calculated with the formula: forecast productivity / actual productivity. We found that out of habit the designers had organised themselves into the sequential waterfall they were used to. As a result, tasks were done one after another, and developers lost time switching in and out at different stages, with delays caused by the need to finish tasks they had already started. Conclusion: probably the most painful story for us, the one that did the most damage and was not spotted straight away. You need to check regularly that every team member has switched to working to the new standards.
2. Unnecessary work on functionality nobody needed. In the second sprint the product owner gave in to the opinion of one head teacher who believed the "curator's journal" was extremely important functionality. We took the story into the sprint and spent effort on it. Why this was a mistake: the tool could only be tested at later stages, because it needed accumulated data that did not exist at the time. As a result, it was not tested, not used and not developed further. The functions that were actually needed were solved differently and not at all the way that head teacher imagined — through completely different tools. Conclusion: only take on work that people will start using straight away.
3. Targeting advanced users. At one stage we took on a story about a "substitutions editor", and a teacher who was a very experienced computer user took part in its development. In the end we got an excellent tool, but ordinary school teachers, who were not that advanced, could not use it. Conclusion: validate stories with regular customers.

General conclusions and the result

Conclusion No. 1. On flexibility: SCRUM lets you be an effective team

The results of every sprint depend on the incoming tasks, on efficiency, coordination and accountability within the team, and on quality feedback. The input is provided by the product owner. They are also responsible for the context in which the functionality will be used and for the quality of the requirements, and they ensure a sufficient depth of detail.

SCRUM requires the team to complete a genuinely tangible piece of work that produces value — a tool that can be handed to the user at the end of every iteration. This helps you see solutions in action and understand at early stages what needs to change in order to move forward.

Conclusion No. 2. On using resources as efficiently as possible

SCRUM is a way of organising work that benefits both the client and the contractor. Working in iterations makes it possible to understand at early stages what is going wrong, and therefore to make corrections in time. Preparing for every sprint and the specifics of how it is organised help you do only what the client needs each time and avoid going off course. And that delivers colossal efficiency in the resources, time and effort spent. The client gets a working part of the system at the earliest stages: after the first sprints they put the completed functionality to work and test it in practice.

SCRUM — when both sides are protected from risk

The barrier that puts the contractor and the client on opposite sides in classic project management disappears. In principle, the positions of "client" and "contractor" disappear, and a team remains. And there are no conditions for potential confrontation.

In just seven months we built a working system that fully satisfies the client — one they had verified in practice and one that reflects all their wishes. Rather than handing over a system designed theoretically against a technical specification that would then have needed several more months of tweaking, because practice inevitably makes its own corrections.

Globally, this case is about choosing the right project management method under a high degree of uncertainty and with limited time before launch. With such a demanding client and such high quality standards, it was at times very hard for us, but also very interesting. The challenges we overcame, the mistakes we made but recognised and corrected in time, and the conclusions we drew changed the culture in our team for good.

And the client received an excellent product: a set of tools for a modern school, capable of quickly transforming it into a school of the future.

Materials and literature that helped us

• Software Estimation: Demystifying the Black Art (Developer Best Practices)
• Manifesto for Agile Software Development
• Principles behind the Agile Manifesto
• Agile Retrospectives: Making Good Teams Great
• Verheyen, Gunther. Scrum — A Pocket Guide