The Switchplane team use a lot of Agile Scrum project management terminology on a daily basis to refer to different processes and milestones in our work. Following on from our previous article, “What on Earth is a Sprint?”, we thought it might be helpful to put together a glossary of terms to decode our language!
This is the name of the software development process we use at Switchplane. Although this system of project management was originally designed for banking institutions, it is highly applicable and commonly used in software development. The framework is based on continual improvement, iterative development, and encourages a rapid and flexible response to change.
The name for the stuff that happens in the background on a website. These will often never be visible to the end user. It includes the way that data is stored behind the scenes, responding to things that a user has done, and any processing that is required.
This is a collection of features, fixes, and requirements that are needed to deliver a product. Items are prioritised from the backlog and brought into a Sprint based on considerations such as risk, business value, dependencies, size, and date needed.
These are problems which prevent a particular request or next step from being completed. These are generally raised by developers in our Daily Stand Up meetings: it may be that more information is needed before a request can be completed, or another step needs to finish before a developer can make a start on a request allocated to them.
Once a month, the whole team goes out for burgers. See the places we’ve visited and rated on our dedicated Burger Day page.
This is a graph that is produced, known as a "burndown" chart, which shows whether we’re on target to complete the tasks by the end of the Sprint. Ideally, it should be a nice downward-sloping line, meeting the bottom axis at the end of the cycle.
These are our regular meetings which are part of the Agile Scrum Sprint process. They include Sprint Planning, Daily Stand Up, Show and Tell, and Retro.
This is a list of site updates that have been completed with a new release to a website. The developers keep track of the changes made throughout the project, and we share the changelog for a particular release with our clients.
The CMS, or Content Management System, is the area that administrators can log into to make changes to content on a website. The amount of access an administrator has can depend on the design of a website, and how much will need to be changed on a regular basis.
This happens every day at 10am. The whole team get together to see how progress on the Sprint is going (using the ‘burndown’), and to see if there are any issues (‘blockers’) arising which prevent a developer from completing a task. This normally takes about 5 minutes to complete, and it’s a great way for ensuring that everyone is on track.
These are our developers - the people working away on code in the Switchplane offices. We have one of the largest teams of devs in Sussex, and all work is completed in-house.
This is the name for the part of the website closest to the user. Work done on the front end will always be visible using a web browser. It encapsulates the look and feel of the site as the experience that the user has when interacting with the website.
This is our own internal system for managing requests and for running our Sprint cycle. We’re really proud of this and apply our own principles of continuous improvement to make our own web app as good as it can be.
Once our graphics designer has put a website design together, our front end developer Dean does a bit of magic with the visual presentation of a web page, to make it look awesome, as we showcased during Sprint Deanify in early 2018.
This refers to Minimum Viable Product. This is a product with just enough features to satisfy early customers; the intention is then to get their feedback as soon as possible to influence future development of the project.
This is our Operations Team, headed up by Donna and supported by Sarah B (Operations Assistant), Geoff (Office Manager), Christian (Graphics Designer), Sarah C (Project Assistant), and Garry (Digital Marketing Manager).
The Project Champion is the lead developer involved in the project. Whilst other developers on the team will work on various requests throughout the life of the project, the Project Champion has the overall context and roadmap. The Project Champion typically attends meetings with clients to help make decisions on the best next steps, and will carry out the necessary planning work to get these requests allocated into a Sprint.
This is a term used when cleaning up code. There are multiple reasons why you might want to refactor a piece of work. It could be to make it more readable for the next person who comes along or to make room for an additional piece of functionality. It is something that is done regularly in the development process, some argue that you should spend more time refactoring than writing the code in the first place!
When a new feature is asked for by a client, we break this down into a series of smaller requests, which can be completed and delivered in one chunk. A number of requests make up a Sprint, and the time needed for these is estimated during Sprint Planning sessions.
A release is essentially an update to a website. Some behind-the-scenes work is necessary to make this possible, and this is more in-depth than simply making changes to the administrator area of the content management system.
The retro, or retrospective, is one of our Sprint ceremonies that takes place for the Development team every second Thursday and every second Friday for the Operations team. In the retro, the teams look at what went well, what went badly, and raise any other comments to help with the concept of continuous improvement.
This is the specific framework of Agile software development that we use; it is an iterative and incremental framework for product development. Time is broken down into Sprints of a fixed duration - for us, we use two-week cycles. During these periods, we hold a number of Sprint ceremonies which facilitate the process and enable our client work to be allocated for development in small, deliverable chunks. For a full explanation of Scrum, watch this 10 minute video.
Internally, we hold this Sprint ceremony on the second Thursday of the cycle. The developers gather together and demonstrate to each other the work that has been completed on their projects in that cycle, so that the whole team has the full context of the current state of the project. Externally, at the beginning of client meetings, we will typically Show and Tell the progress made on the project since we last met.
This is our preferred method of internal communication; we’ve almost eliminated email internally. Slack is like an instant messenger system, but with hundreds of useful add-ons. For clients we work with regularly, we encourage starting a Slack workspace to enable fast and to-the-point communications without any of the extraneous noise.
A spike is a piece of investigatory work that needs to be done in order for the requests to be worked out and allocated. It helps provide a clearer picture of the problem and its solutions.
A Sprint is simply a two-week period of planned project work. Under the Agile ethos, instead of attempting to plan an entire project, we break it down into manageable chunks called Sprints. We allocate 60% of our working hours to each one. That leaves time for us to cover unexpected issues arising with non-Sprint projects, such as a problem with a client website or some other issue which is too urgent to wait for the next Sprint cycle. Read our “What on Earth is a Sprint?” article to find out more.
This is an internal meeting which happens every second Friday; each Sprint is planned individually. The developers plan out their client requests in advance of the meeting, then as a collective and with their knowledge of various aspects of the project, they will make an estimate regarding the time required to complete it. This could be from one hour to 16 hours. The time chosen by the majority is then allocated to the task. That might sound a bit unreliable, but you'd be surprised at how close the views are between team members on how long a piece of work will take.
This happens both internally and externally with our clients. Internally, we often meet outside of Sprint Planning sessions to fine tune what is needed technically for the next stage of a project. Externally, we meet with our clients regularly to find out what are the next priorities in the delivery of the project as a whole, and decide what our next steps should be together.
This refers to a block of time that is set aside or allocated to a particular task. This is usually used when there are larger tasks which need chipping away at, or perhaps for a spike to investigate a problem further.
The user story is a collection of phrases and sentences that capture a description of a software feature from an end-user perspective. The technical requirements can then be derived from this. For example: As a user, I would like to understand the Agile process a little better!
These are the very bare bones of a design concept, put together to ensure the required elements are present on a page. Once the basic structure is there, the design can be fully developed and fleshed out.
Can we help with your project?
Get updates on everything Switchplane by joining our newsletter.
Our opening hours are 9am - 5pm, Monday to Friday.