Your browser is no longer supported. Please upgrade your browser to improve your experience.

What exactly can you expect when you start a “sprint” with us?

A “sprint” is an Agile term referring to an iteration within a software development project. For us, it is defined as two weeks (10 working days) with at least one developer and sufficient test engineering time to cover testing for working on a client’s embedded software. Sprints are an important part of our Lean-Agile approach to software development.

We measure our projects in sprints because we believe that using an iterative process and having as much feedback with the client as possible is imperative for the success of a project and ensuring quality. At the end of each sprint, the client is provided with a release of working software and reports to feed back on, so that they’re always aware of what’s happening at each stage of the project, and can see progress happening regularly.

This Agile way of working has been proven to be more successful than the traditional Waterfall method, whereby the client wouldn’t be able to see or feedback on any progress until very late in the project, or even until the project is complete. By using sprints it means that if there is a change in direction during the project, the cost to implement those changes is much lower due to the regular feedback (rather than waiting until the end of the project).

So what happens within a typical sprint at Bluefruit?

1. A Three Amigos Meeting

We organise a pre-sprint meeting with the Product Owner (client) in order to decide which stories (user experience journeys through each feature) to prioritise for the sprint, and agree Acceptance Criteria (testable scenarios for those stories).

We refer to this meeting as a “Three Amigos”, because it usually includes at least one developer (normally two, in order to ensure quality throughout development), one test engineer, and the Product Owner. During this meeting we use a technique called Behaviour-Driven Development (BDD), which means that the group will use a ubiquitous language to come up with stories for each feature so that everyone understands the function of each feature clearly.

3 amigos meeting
2. Planning Meeting

Our development team will then have a planning meeting to discuss the detail of the design and implementation in order to fulfil the Acceptance Criteria agreed in the Three Amigos.
In this meeting, our team will also estimate the effort involved in each story point, so that our expectations of what will be completed within the current sprint can be fed back to the Product Owner.

3. Story Development

Our team will now start the sprint, during which the stories will move through the following states:

  • To Do. This is where the stories that haven’t been started yet originally get placed.
  • In Progress. This includes anything that is currently been worked on (usually a maximum of 1 story per developer).
  • In Review. This includes work that has been pull-requested, but not merged, and needs to be reviewed by another developer before it is merged.
  • Done – never tested. This work has been merged into the project, but not tested yet.
  • Done – mid sprint tested. This work has been merged and tested during the sprint.
  • Done – release tested. This work has been tested at the end of the sprint and is ready for release to the client.

Kanban example
4. Release Report

A Release Report is put together and sent to the client at the end of the sprint. This will include:

  • A list of all stories completed within the sprint
  • Detail of each story’s Acceptance Criteria and whether they currently pass or fail the tests for those criteria
  • The velocity for the sprint period (the rate at which the development team were able to complete stories)
  • Any factors the team believe may have affected the velocity

5. Sprint Retrospective

Once the Release Report has been sent out, our team will have a sprint retrospective. This is a meeting in which the developers and testers reflect on what went well throughout the sprint, and what needs to change or improve in the next sprint. This is how we empower developers on the ground to achieve process change.

6. Product Owner Feedback

The Product Owner will then provide feedback on the release report, which will feed into the Three Amigos meeting at the beginning of the next sprint.

Looking for software engineers who put quality first?

Using sprints is just one of our many Lean-Agile ways of working that enables us to ensure quality outcomes for our clients. If you have an embedded software project you need engineers for, speak with us today.

Find out more about Lean-Agile

Did you know that we have a monthly newsletter?

If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!

Find out more