Customer Traction

Reading Time Time to read: 7 minutes

How to run a sprint for a small startup product team

Alex Williams

Front-end Developer @ Forward Partners

Developing a product that customers will love, quickly and efficiently, requires managing your product team carefully. Your team may still be small but your product is moving and changing quickly. At Forward Partners we help small teams by using a sprint process. In this short article I will expand on what makes up a sprint, and how you can apply it to your startup’s product team.

Key takeaways

A great sprint process is made up of five key components: backlog grooming, sprint planning, daily stand-ups, a mid-sprint review, and an end-of-sprint showcase. Building these five activities into your sprint will:

  • help your team manage and prioritise tasks that need to be done in the coming weeks;
  • keep track of how the product is developing; and
  • demonstrate to your key stakeholders what you’ve achieved.

What is a sprint?

To build a product in a startup you have to work uncomfortably fast. You have to deliver an initial product as quickly as possible to test whether your potential customers relate to it. At Forward Partners we are able do this by managing the day-to-day life of the product team with a process commonly referred to as Scrum (see also Kanban for an alternative approach).

Scrum is characterised by the team working in ‘fixed-length iterations’, or sprints, to build a product. A sprint can last a week, but more commonly two weeks, and involves committing to completing a set number of tasks during the sprint. Once the sprint ends the product team reviews how well the sprint went (in a retrospective) and plans for the next. This process then repeats and allows the team to constantly iterate on the product, incorporating feedback as it comes in from customers and stakeholders, and fixing bugs as they are discovered.

As an aside, very early stage startups could use a shorter sprint or consider using a kanban approach, and move to two-week sprints once the product has taken more shape.

At Forward Partners we normally encourage our companies to work in two-week sprints. The benefit of two week sprints are that we, as a product team, are able to fit backlog grooming, a showcase, and a sprint planning session into our schedule without dramatically reducing the time we have to work on the product.

A good sprint starts with backlog grooming. Then you plan the sprint. During the sprint you keep on track with stand-ups and a mid-sprint review, and end the sprint with a showcase of what has been achieved. Let’s explore these stages.

Start with grooming the backlog

All sprints start with a list of features that need to be built. This is commonly referred to as ‘the backlog’ and is a list that the founder (or in larger or more well established teams, the product owner) has compiled to develop the product in the long-term. The features are often quite high-level, for example, building a user accounts functionality.

The first step in preparing for the sprint is to groom the backlog. Grooming involves breaking these high level tasks, also known as epics, into smaller, more manageable tasks. For example, a common early stage epic could be to build a landing page. This epic needs to be broken down into designing the page, building the user interface (the front-end), and setting up and required website infrastructure (or the back-end). These tasks could be broken down even further, for example, designing the page could be broken down into design the hero image, and design a carousel of quotes from satisfied customers. Once the tasks are small enough that you are happy that you can estimate their complexity the team should discuss with the founder the order that the tasks should be completed in.

This will leave the team in a position where they have high-level features broken down into manageable tasks, ordered by what they should start working on first. We suggest you groom the backlog a few days before your sprint planning session. If your sprint planning session falls on a Friday (so that the new sprint can start on the following Monday) groom your backlog on the previous Wednesday. This gives you a a little wiggle-room between the two for scope to change.

Planning the sprint

Once your backlog has been groomed and ordered you can move to planning the sprint. If your backlog grooming has broken down the epics into small enough tasks, and prioritised them effectively then this session needn’t take more than half an hour. Sprint planning involves taking the list of small tasks and assigning points to them based on either their complexity or on how long you estimate they will take to complete.

For example, at Forward Partners we use a system whereby each team member can complete 40 points per two-week sprint. In our sprint planning sessions each team member will assign points to tasks based on how long we estimate they will take to complete. For example, building a carousel of the home page could take a full day of time and so is allocated four points, whereas updating the copy on the website’s ‘About Us’ page would take a much shorter amount of time and so be allocated half a point. In this example, once the tasks have points allocated to them each team member will be able to assign 40 points worth of tasks to themselves for the upcoming sprint chosen based on the order set out during grooming.

When should you plan your sprint? We have had success planning our sprint on a Friday afternoon just after our team retrospective. It doesn’t take too much time out from the previous sprint and allows us to start the next sprint on Monday without having to go straight into a planning session.

Keep on track

There are two ways the team can keep on track during the sprint: daily stand-ups and a mid-sprint review.

Daily stand-ups are an opportunity for the team to meet every morning and update each other on which tasks have been completed, which are blocked and that they need help with, and which they will be embarking on that day.

In a nutshell, pick a time early in the morning that fits with the majority of your team (at Forward Partners we stand-up at 09:45) and spend 10 minutes updating the team on what you worked on the day before, what you will be working on today and whether you need any help to unblock a task. You can read more about how to run an effective daily standup here.

While daily stand-ups will keep you on track for the majority of the two-week sprint it is useful to hold a short mid-sprint review. A mid-sprint review involves catching up with the team to see whether they are on track to complete all of the tasks assigned to them in the sprint. This is a good opportunity to look at the teams velocity: how many points they have completed since the beginning of the sprint.

At Forward Partners by the time we reach the mid-sprint review each team member should have completed approximately 20 points. If a team member is trailing behind what’s expected the team can identify whether anything is blocking a task from being completed and take action with enough time left to finish the task before the end of the sprint.

As with sprint planning time-box this to half an hour and make sure any changes are reflected in your sprint-management software of choice (e.g. Trello, Jira, Target Process).

Unanticipated changes to the sprint

Even with careful backlog grooming and sprint planning you will find that during the sprint new tasks arise that take priority. This often happens in response to discovering a bug or critical problem with the product, or an unexpected external requirement. For example, the founder is unexpectedly booked in to meet a possible investor and she needs an updated slide deck. This means that the team’s designer needs to add a new task to the sprint, and that task has been estimated at four points (an extra day of work).

The best way to incorporate unexpected tasks is to look at the current tasks in the sprint and de-scope (or remove from the sprint) the least important tasks until you have four points available to be allocated to the new task, in this example, designing a slide deck. You need to be strict with de-scoping otherwise the amount of tasks you commit to will creep upwards. If this happens you will find that your team does not complete the total number of points committed to. At the end of the sprint all the remaining tasks will have to be ‘rolled-over’ to the next sprint. This is a red flag if this begins to happen regularly.

Alternatively, if the unexpected change is more serious, for example, a change in product direction, then the last option is to abort the sprint. I have rarely seen this happen, however it is an option for early stage products which often have to change quickly in reaction to new customer demands.

End the sprint with a showcase

When should you showcase your work? At Forward Partners we showcase our work on the Thursday afternoon before the Friday sprint planning session. It allows us to gather feedback from the founder and any team members working outside of the product team.

Try not to limit the showcase to technical or visual changes. It is an opportunity for the whole team to show what they have been working on. Therefore show-off work on product growth, successful user interviews, and infrastructure performance gains, as much as improvements to the user interface.

It usually takes us an hour to show our work, field questions and note down any feedback  from the team. An end-of-sprint showcase marks a soft-end to the sprint, and arms us with feedback going into the sprint-planning session the following day. Then we start the process again.

Useful links

Alex Williams

Front-end Developer @ Forward Partners

Front-end developer for Forward Partners. Helping our companies build a scaleable and maintainable codebase.

Apply for Office Hours

We’re looking for great entrepreneurs with great ideas.

Apply here

Similar Guides