Agile Development_

What is Scrum?

Our projects are run using agile methodology. Scrum is our preferred approach for effective web and software development and project delivery. Scrum provides the project structure in terms of roles, meetings, rules, measures and documentation. How does it differ from other methodologies?

Scrum is an iterative approach where a product is planned and delivered in bite sized chunks which is unlike the more traditional waterfall approach, where all the planning occurs upfront and the product is ordinarily delivered at the end of the project. The benefits of using Scrum is that customers can see continued progress in development and offer feedback and revised priorities as the project develops.

The Team

Scrum does away with the traditional project manager and opts instead for three key roles:-


The Product Owner

Product owner has the vision and are responsible for said vision, prioritisation of effort, which is the link to customer stake holder and is the point of escalation.

They are the decision maker and point of escalation.

Scrum Master

Controls the scrum process, resolves project blockers, helps to organise the team, shielding them from interference while improving process. Maintains project controls in terms of backlog and delivery performance which should be measured in the form of burndown so that we can continually monitor progress and expected timescales to deliver all user stories.

The Engineering Team

The team of self managing and self organising developers, testers, designers and analysts working collaboratively to develop the product.

Backlog

Working with the project stakeholders (customer) the product owner along with relevant analysts will in the first instance establish the epics (the high level stories that make up the scope of the project) The product backlog will be formed by establishing user stories as we are able to expand and better define the epics.

As part of a collaborative exercise with the project team, the epics are broken down into more palatable user stories where definition is applied to include acceptance criteria or conditions of satisfaction. E.g. An epic: the system must contain user account management. This epic could cover many user stories, one of which might be as a system administrator I must be able to change a user’s password where conditions of satisfaction might be listed as:

  • Password must be minimum 8 characters

  • Password must contain letters and numbers

  • Password must not contain reserve characters

  • There must be password confirmation

  • There must be a strength indicator

The agile web development team and more usually the lead developer will size the stories indicating where further definition is required. The product owner based on the understanding of the product, the customer and the sizing will prioritise the stories. For new projects this will be the opportunity for the product owner to identify that the user stories that make up the minimum viable product. The MVP is defined as the fewest number of features to take a product to market. By prioritising user stories in the backlog the project stakeholders can be assured that development efforts is focused on the most important aspects of the project.

Sprint

Scrum uses fixed length periods of development called Sprints. Typically we would work to a 2 week sprint where planning proceeds development, where testing runs hand in hand with development and review completes the sprint. In most cases the sprint will represent a theme or section within a project with the aim of delivering a complete set of functionality to the customer.

Planning reviews & retrospective

Sprint planning is where the development team commit to a set of user stories from the product backlog based on priority and size. The discipline here is to encourage the team to remain focused on the stories exclusively within the sprint. So sprint planning must involve the key members of the team.

Sprint planning involves the key members of the project team where user stories are reviewed, definitions discussed and where the engineering team commit to the user stories that can be delivered within the next sprint based on the resource availability, story priority and size. Where stories of larger size exist these can be broken down into smaller more manageable stories.

Sprint review meeting occurs at the end of a sprint where product can be delivered and so a feature demonstration can take place with the key stakeholders to show progress and discuss upcoming features.

Sprint retrospective also occurs at the end of each sprint. This is conducted within the project scrum team, where process can be reviewed and honed to improve past events to improve process and product delivery to continually improve process and delivery for future sprints.

Throughout the project there may be continued refinements of the product backlog to improve story definition and re-prioritise according to an improved understanding of the project and/or customer feedback. The discipline of scrum is that each sprint is set where the engineering team can focus on their tasks ahead and only in extreme circumstance can stories committed to be swapped out.

We would love to hear from you

To find out more about our services and how we can help your business please get in touch on 01722 744574.

Alternatively please use our contact form and we will get back to you as soon as possible.