So, what's it like to work with us on an agile project? Although every project is different, we always stress the importance of close and regular collaboration, short feedback loops and creative solutions. The descriptions below should give you an idea of the activities that take place on our typical Scrum projects.
Before any sprints start, we get together with you to discuss the scope of the entire project. The main objective of this session is to create a prioritised product backlog containing the user stories that are deemed necessary to develop an application that will meet the project's business objectives.
We often provide a release planning session for free, during pre-sales. Rather than spend time and effort writing a spec document to send to web development companies, why not contact us to arrange a release planning session?
A project consists of a number of sprints, each of between one and two weeks in duration, which run consecutively usually with no gaps in between.
During sprint planning we will work with your product owner (the client representative) to break down the highest priority user stories (those at the top of the backlog) into smaller stories – as far as is possible so that, when finished, the features developed for a story can be shipped to provide real value to users. For each story we will define with you acceptance criteria, so it is clear to everyone what the solution must do in order for it to meet that story’s requirements. Breaking larger stories into smaller stories means more detail is discussed, which reduces the scope for misunderstanding. It means that a feature can be shipped to users sooner, shortening the feedback cycle, and increased transparency – it becomes clear what the developers are doing, which reduces the chance that they get bogged on tricky but less important tasks.
At the end of the sprint planning meeting we will have a prioritised set of stories for the sprint, understood in enough detail for the developers to start working on them immediately.
During the initial sprints, we will work with your product owner to understand the vision for the brand and visual design of the website or application. Our graphic designer will produce strong visual designs that deliver on the creative objectives of the brief and are perfectly aligned with the overall brand vision.
The graphic designer will develop creative concepts for some of the key pages. We will review these with you, collecting any feedback leading to the finalisation of a chosen concept. This concept will then be carried across the design of the whole application.
Before the developers start work on a user story that requires interaction from the user our UI developers create wireframes of the key pages, so that we can obtain early feedback from the product owner on the UX design of the pages.
The graphic designer will be involved in this process for the main pages in the application, to ensure the visual design objectives are considered at an early stage. Once wireframes are agreed our graphic designers will create proofs for these key screens and we will go through a cycle of review and approval of these screens (with the product owner) before development begins.
We often use the principle of ‘design ahead’, whereby for stories that will require significant UX design wireframes are created on one sprint and use on the next sprint when the actual development work will take place.
The developers will decide as a team who is going to work on which stories. Sometimes more than one developer will work on a story (or specific problem in a story) at once using pair programming, particularly for the more technically-challenging areas. The developers use Test-Driven Development practices, which means they will write (initially failing) tests before they start to code a solution – ensuring that we have comprehensive, automated tests for the entire application.
If a developer has any questions about the requirements for a story, or wants to discuss some possible options for a solution, they will communicate directly with the product owner.
The team meets every day, in the morning, to discuss progress and to plan their day's activities. Ideally the product owner will join the daily Scrum to ensure an open communication channel for quick resolution of issues and effective planning.
When the team has finished the coding for a story, the product owner is invited to review the feature. The product owner can then provide immediate feedback, including requests for changes to the solution, which will be considered by the team for inclusion in the current or a future sprint, depending on priorities and available capacity.
When the solution for a story has been demonstrated to the satisfaction of the product owner, the team will ensure that all of the other ‘definition of done’ criteria have been met. When they have, the story will be classed as done.
The sprint review is a short presentation of the stories completed in the most recent sprint. Ideally, the sprint review is presented by the product owner.
If possible all stakeholders should join the sprint review as it is an opportunity for them to provide early feedback. Their feedback can be reviewed by the product owner and can be included in the next sprint’s work to have immediate impact.
The retrospective usually lasts about one hour, and includes all of our project team and the product owner. The objective is to learn and improve for future sprints by discussing what went well and what could have been better, and (from the latter) producing specific actions to take into the next sprint.
How does an organisation develop a culture of performance? How does it ensure that its teams are all high performing? Martin discusses these questions in an article for CMSWire.Continue reading... Dec. 15, 2016
Occasionally, as is the case with The National Archives, we get to work with clients across both sides of our business. In addition to custom web software development, Bright Interactive is also the company behind Asset Bank, industry leading Digital A...Continue reading... Dec. 16, 2015
Each of the speakers present demonstrated a real love for type, each brought their own case studies and demonstrations of effective uses of type on the web or in print. Here are just some samples of the useful and interesting things I picked up on from...Continue reading... Nov. 16, 2015
Last year, Mark Otto from Github wrote a popular blog post on how they go about architecting their CSS. Inspired by this spirit of knowledge sharing, other designers and engineers have since followed suit, including Mark Aparicio at Groupon, Brian Lovi...Continue reading... Nov. 5, 2015