We often hear from our clients that they thoroughly enjoy working with Somar, from the initial workshops through to the agile process and delivered end result. This is largely due to how we actively involve the client from start to finish. We believe that the client is just as much on a journey as we are, and we would like to share a little bit of that process with you.
As part of our agile methodology, we follow the Scrum approach - an iterative and incremental framework for managing product development. It’s a flexible, holistic strategy where the design and development team work closely as a unit with the client (or product owner) to reach a common goal. It enables teams to self-organise by encouraging close collaboration and daily face-to-face communication among all team members and disciplines involved.
During our pre-sprint planning sessions, which lead each body of work in a project, the team discusses the scope of what they will be building - which includes sizing user stories(external link) on the amount of effort required for each. Somar use what is known as relative sizing, which allows us to gauge the velocity of sprints(external link) in order to maximise what can be achieved over the project’s timeline.
Often these sizing exercises involve the client so that they can get an understanding of what is involved and help expand on the acceptance criteria (or requirements) of user stories as we go around the table. We appreciate that these pre-planning meetings, while essential to a successful outcome, can be sometimes a bit tiring with a lot of technical jargon being thrown around.
To help counter this, Somar has developed our own series of planning poker(external link) cards to help inject some colour, and encourage more active discussions while trying to estimate stories as a team. Because stories are sized relatively, planning poker cards revolve around a Fibonacci sequence of numbers, with the larger numbers indicating complicated, or uncertain development tasks.
By supplying more details, or breaking these stories down into smaller stories, we aim to get the estimated number down to the smallest possible before entering them into the sprint. The more manageable the story, the more likely we are to complete it within the sprint.
The reason playing cards are used is to encourage freedom of thought. Each member of the team places their card face down on the table before they all reveal their numbers at the same time. This eliminates the influence of the other participants, as when a number is spoken going round the table, it can often impact the following participants' sizing as they second guess themselves.
Once all the cards have been revealed, any members who have particularly high or low estimate numbers are given the floor to discuss why they think this might be the case. For example, it could be a user story that has a complicated feature that no-one else has considered, and so a slightly higher estimate provides some security to get it completed.
We understand that every member of the team has different areas of expertise, or familiarity - and are therefore going to be more efficient at particular tasks than others. But the aim is to have the consensus of everyone working on it, because the delivery of the sprint will be the responsibility of the team.
Conclusion
Our clients have appreciated being a part of the scrum process. It’s a system employed by most other agile web development companies, however, we are proud of now having our own branded, fully illustrated deck of cards for such an occasion to help inject some colour and humour into the planning sessions.
If you’re interested in working with Somar and learning more about how we engage in scrum and our agile development, click below as we’d love to talk to you.
