How we use Scrum

Since the start of Easy LMS, we have embraced the Scrum method. This method allows us to develop our learning platform, as a team, in an effective and flexible way. How Scrum is used differs by organization. That's why we’ll take a look at our Scrum kitchen 😊.

A three-week sprint

Let’s stick to the sports jargon for a bit. We work in three-week sprints, although that might almost feel like a marathon 😉. A sprint is a set period in which a multidisciplinary team – from designer to tester – works on the same project. This team works with the product owner, which is me in this case. The product owner is the overall boss and makes decisions together with the team. Do we spend time on figuring out that link with Amazon or not? Do we have to add a new Knowly owl? Or, is adding Calibri as a font in the certificate editor enough?

Many team members don't work on Mondays, which is why sprints start on Tuesdays at 10:00 am with a sprint planning. During this time, we put our heads together to discuss what we are going to build. We also set our sprint goal. For example: The user should be able to download the certificate and view his/her Exam score. We follow the roadmap as much as possible, which has been set by the overall bosses.

The user always comes first.

We cannot emphasize it enough; the user always comes first. Therefore, we create a user story for each adjustment or addition. A user story is a short description (story) of what the user wants and why. An example: In order to understand the interface, as a participant I want text labels to appear in my own language. We look at a story from different angles and write down criteria that the story must meet. We call these acceptance criteria. This way we ensure that we will not forget anything.

Poker for priority

This step might be the trickiest part: we must prioritize all user stories. We always have limited time, and a huge list of new additions. We are bursting with new ideas, partly prompted by the nice feedback from our clients.
Our team makes an estimate of the required user points for each story to fully complete the story. We use planning poker to make an estimate. We always wear a poker face at work 😉.

A poker card set includes multiple sets of cards with the numbers 0, ½, 2, 3, 5, 8, 13, 20, 40, and 100 (based on the Fibonacci series). These numbers symbolize the complexity and quantity of a task in points.

Only stories we expect to complete, will make it to the sprint.

At the end of the sprint planning we have a point estimate for each story. After all these years we know how many points we can complete ("burn") during a sprint in various team setups. We determine the key stories based on time, the impact on the product, and the value for participants or clients. We put them first. Only stories we expect to complete, will make it to the sprint. We park the others until the next sprint.

Get up, stand-up

After the sprint planning, the tasks are divided and we are ready to go. Finally! Each day at 10:00 am we do a stand-up. The daily stand-up is intended to update each other. This takes about ten minutes and everyone tells:

• What he or she has been working on.
• What he or she will be working on today.
• Whether something is holding him or her back.
• Whether there are any challenges that day.

Once everyone has had their say, we will also discuss the following three points:

• What should we do to complete the key stories?
• Are we on schedule for our sprint goal?
• What about the target conditions?

Every week a retrospective

At the end of each sprint week we look back on our performance. What went well, what could be better, and what do we never want to happen again? By asking these questions, we immediately find points for improvement that we can implement in the next sprint week. This helps us to always stay on top of our game.

It does happen that a sprint goes differently than expected.

After three weeks

After three weeks, we have completed everything that we had planned – everything is tested, approved, and bug free. Only joking! It does happen that a sprint goes differently than expected. Sometimes stories take longer than expected, or it is better to invest more time in a certain functionality. As a result, something cannot be made. That is a pity, but not a major problem. After three weeks we always have a working whole that has been tested - and where the bugs have been solved - and that is usually already live.

We already look forward to the next marathon, sorry sprint 😊.