Finished sprinting? Now what 👀

In our ‘The NEW way of working at YPA’ article we tell you all about our processes of working in sprints. Besides all the beautiful platforms we’ve built, we also maintain them. In this article we tell you more about the process after we have delivered a sprint.

5 min leestijd

daan + wes

As YPA we have the honor to work on beautiful platforms. As you know from the blog from my colleague Fleur, we work with ‘sprints’ to develop The platforms. We use sprints to work on new features and bigger improvements of the platform.

Along with the development sprints we do service sprints to give continuous development on the platform. This way a client is still able to do small adjustments without waiting for a bigger sprint.

What makes the difference?

The difference between a sprint project and service work really depends on the complexity of a request that came in. That’s why we have built a workflow to easily qualify if a request needs to be picked-up by the responsible team. The 5 steps you need

The steps:

  1. The inbox
  2. Qualification
  3. Ticket preparation
  4. Estimate
  5. Planning

📥  The inbox

The key to success for a good service workflow is an inbox. This is a place where a client can send in all requests: Questions, tasks, feedback, features, bugs and improvements. This inbox principle is also used in a well known productivity system called: Getting things done by David Allen. The next step is the qualification of the request, to see which team is responsible for it. This way we can give the best of both worlds, sprinting to improve the platform and service to maintain the platform.


👩🏽‍🎨 Sprint project team

  • New feature
  • Improvement big


🥷🏼  Service team

  • 🚨 Bugs
  • Improvements small ( < 3 story points )
  • Research / questions / Tasks

🚨  What is a bug? 

A bug is simply something that breaks. Your platform has a lot in common with a house. It’s built in a certain way and changes in the environment can have an impact.

The service team will do everything to solve a bug as quickly as possible.

Bugs are prioritized as:

  • Urgent: Catastrophic application / website failure
  • High: One or more features are not working. The workflow is interrupted. There is no workaround.
  • Medium: One or more features can not be used. The workflow is reduced. It’s still possible to work.
  • Low: Only visual disruption or minor issues. Workflow is not impacted. It is just ugly or unimpressive.

🎨  Small improvements

In the intro of this blogpost we mentioned that we want to give our customers continuous development next to the development sprints we do. This way we can grow a platform, but also have time and resources to maintain the platform.

To do so we need a clear view on what kind of requests can be picked up by the service team. Over time we have learned that we can pick up small improvements with an estimation of 3 story points. These are requests that can always be picked-up within one day.

Some examples:

  • As [COMPANY] we want to add an extra section for reviews to our order confirmation email
  • As [COMPANY] we want to change the CTA (Call to action) on the product page from orange to green to boost conversion
Daniel coding

➕ What is a story point?

Tickets are estimated in story points, but what is a story point? Story points are made by the Fibonacci numbers 1, 2, 3, 5, 8, 13 till 21 to estimate stories in complexity and not in hours. There is no way to attach a specific time range to story points, this can vary per project and also developer.

This is an example of how you can look at story points:

  • 1 story point: > 1 hour
  • 2 story point: 2 to 3 hours
  • 3 story point: 3 to 5 hours
  • 5 story point: 6 to 8 hours
  • 8 story point: 12 hours
  • 13 story point: 2 to 3 days
  • 21 story point: Breakdown. Make it smaller.

🧮  Estimation session

Estimation sessions are sessions that we have introduced in our weekly routine. Every Tuesday and Thursday we have a preparation session and an estimation session. In these sessions we do preparations of all tickets that came in and estimate them on the complexity of the request.

All tickets that are above 3 story points will be picked up by the project team. The rest of the tickets will be picked up by our service heroes and can be categorized as TLC, tender, love  and care 💛

📅  Qualified, estimated and now what?

Now that we have the estimation of the ticket, it is time to plan it in. The most efficient way of planning work is to combine and bundle tasks that are related. To secure time in the planning for our customers we have a development add-on.

This development add-on gives the customer an X amount of monthly hours to always assure that there is time for continuously developing the platform. This can differentiate from 8 hours, 16 hours till 32 hours spread over 4 weeks to pick up improvements or support requests.

🤫  The secret to success

Now that you know the flow of our continuous development works,  there needs to be a conclusion right? A structured flow with recurring processes and clear ownership will give space to build a flow to develop and maintain your clients.

The steps:

  1. The inbox
  2. Qualification
  3. Ticket preparation
  4. Estimate
  5. Planning

Do you have questions about setting up a service flow? Send me a message to [email protected]

Wil je meer weten?

Wessel helpt je graag verder. Wessel is een enthousiaste Haarlemmer die enthousiast wordt van klanten. Doormiddel van open en laagdrempelige communicatie zorgt hij voor een fijne samenwerking met de klant, maar ook binnen het team.

085 060 9386 [email protected]