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 2 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.
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. 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’. This 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 sprint at Bluefruit?
1. A 3 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 ‘3 Amigos’, because it usually includes at least one developer, 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.
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 pre-sprint meeting.
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
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 ‘3 amigos’ meeting at the beginning of the next sprint!