The Digital team prefer to use plain English to describe something instead of using jargon or a technical term.
That said, specialist terminology is sometimes necessary for our meaning to be precise. Or sometimes you might overhear a conversation between our team and be curious about what we were on about. To help you when that happens, here are some technical words and phrases you might hear us use and their meaning in context:
Accessibility is helping people with disabilities to locate, understand, navigate, and interact with digital products and services.
‘Agile’ is a delivery management method that suits digital media projects because it is based on repeating cycles of incremental planning, testing and building.
We like Agile for its practicalities and also its principles. Agile is suited for projects with rapidly changing or emerging requirements, which sounds like most of the stuff we are required to work on. You can start finding out more about Agile and who else uses it with Wikipedia.
A short development phase in which a site, feature or campaign is on closed- or limited-access release to enable some measurement and testing prior to further development.
Analytics are meaningful patterns found in data. We use analytics software, like Google Analytics, to gather and make sense of the traffic generated by our website. Webpage analytics should be reviewed regularly by publishers to develop an understanding of how they are being used, when and how they need to develop.
A web application or app is any application software that runs in a web browser without the need to install separate software on your machine, for example, the University's content management software.
Each product and service has a backlog, which is a prioritised list of work in the form of user stories (preferably) or requirements or tasks. Each item is represented as a card, which carries a description of the work and its acceptance criteria.
There is more than a sprint's worth of work on a backlog, and it is the job of the product owner to prioritise the items on the backlog to be addressed in each sprint. In sprint planning, the delivery team will deliberate on what is involved in delivering each card and how many items are feasible over the duration of the sprint.
A development phase where we are testing a site, feature or campaign at scale in a live, public environment but where we still expect to make significant changes.
The length of a beta phase should be proportionate to the scope of the project. It would probably not be less than a month and not longer than 12 months.
A blocker is something unforeseen in planning that ends up stopping the team or someone in that team delivering their work. Examples include, lack of anticipated information, the availability of a key stakeholder or a meeting that is unrelated to delivery.
Team members should seek to resolve blockers in the first instance and then consult delivery managers and then product owners if things can’t be moved quickly enough or at all in the sprint.
Not working at all well.
Code is the language we use to instruct computers. Coding in this context is using several language(s) to conceive, control and iterate the infrastructure, applications and features that taken together make up bath.ac.uk.
Content can be words, pictures, videos and audio or a combination of those elements brought to together to explain something. Content is produced by people and managed through software.
A content audit is the process of evaluating the results of a content inventory.
A content inventory is the process and the result of cataloging the contents of a webpage, section or site.
Content strategy plans for the creation, publication, and governance of useful, usable content.
The Digital team includes content producers, who can create and edit copy, photography, audio and video to address user needs.
We talk a lot about ‘delivery’ because as a team and as individuals we want to be judged on the basis of what we produce and how we produce it.
Delivery is also a phase in our projects. Most of the time, most sprints are in a delivery phase where we are working on the production of code, content or data.
The Delivery Manager is assigned to each sprint to ensure that the delivery process defined by the team and its constraints is being followed and reported.
The Delivery Manager (usually called a Scrum Master outside of this uni) supports both the delivery team (by making sure they have the space, materials and people to do the work) and the product owner (by making sure they are aware of the delivery status and working through any blockers that may emerge).
Everyone in the Digital team on all projects works to a set of delivery principles. The delivery principles are simple and easy to remember; they help anyone working with us to understand how we go about our work.
These are the principles by which everyone in the University of Bath Digital team delivers their work regardless of the scope or scale of delivery, regardless of whether we are a designer, developer or editor, and regardless of whether we are carrying out the work within the Digital team or in collaboration with someone else.
The Digital team includes designers who are able to program, deploy and maintain site interfaces, page layouts and patterns, and manipulate digital media (such as typography, iconography and photographs).
The Digital team includes developers (or ‘devs’) who are able to program, deploy and maintain web applications.
We are the Digital Marketing & Communications team for the University of Bath. Our friends call us ‘Digital’.
The ‘digital’ in the title refers to media that are encoded in a machine-readable format. In other words, University-related products and services that you access when you visit bath.ac.uk.
Discovery is an important research phase in our projects. It is where we make the time to get up to speed with the user needs and data about a project. Where information is scant, the discovery phase is used to plug the gaps.
Discovery can happen at the beginning of a delivery sprint, or it can have sprints dedicated to it. Scrimping or dwelling on discovery is detrimental to the quality of delivery, so it has to be planned out and proportionate.
Our domain name is bath.ac.uk and it forms the basis for all web addresses used for pages and sections of the University of Bath website.
The work and schedule of the Digital team is subject to a monthly review by the University’s Digital Steering Group. The Group consists of the Deputy Vice Chancellor, the Pro Vice Chancellors, the University Secretary and the Director of Marketing & Communications.
Engagement is using digital tools and channels to find, listen to and converse with a community around a topic or service.
Sometimes a user need can be so big that it consists of a number of stories. Before those user stories are articulated, the need is referred to as an epic.
Estimation of the time and effort it will take to complete a task provides an indication, not a guarantee. The Digital team uses points as an estimation of complexity. The points scale is applied consistently and reviewed often so that adjustments can be made based on team development.
Estimation of backlog items is carried out by the delivery team using points. This then helps the team and the product owner work out what work can be achieved in a sprint. The number of points a team delivers in a sprint is monitored (usually on a ‘burndown’ chart’) and this provides an indication of a team’s likely and actual velocity (which is the productivity rate). Tracking velocity allows the team to work out whether their points allocation is correct and, over time, what their average velocity is in a sprint.
Features are functions within a product or service that fulfil one or more user needs (for example, a search box or a menu). Features can be design and developed, they can be code or content, and they can always be improved.
Functionality can be the purpose that something is designed or expected to fulfil and the range of operations that a product can be put to.
A sprint goal summarises the desired outcome of an iteration. As a rule of thumb, every sprint should have one shared goal to focus collective effort, support prioritisation and guide feedback.
Sample sprint goals are 'Provide editorial workflow for news articles', or 'Provide the ability to subscribe to blog post updates'.
Information architecture (IA) is how a website and its components are organised and labelled.
Infrastructure is the unseen but critical hardware and software that provides the environment for our web content and application hosting. Just like content or website features, the infrastructure needs regularly performance monitoring and development to make sure it meets user needs.
We develop and release our products and services on an iterative basis because we believe that the perfect project is unattainable, that improvements can always be made and that we should always make space for change by not planning too far in advance.
Building digital products and services is a complex task, with many risks. By breaking development into phases we minimise risk, learn about what works and what doesn't, and produces results quicker and with greater efficacy.
We talk about something going into a ‘live’ phase when a project has finished and the deliverables are fully operational and out there on the internet.
A specific project may have been completed but the work on that product or service doesn't stop here. Monitoring begins and subsequent iterations will be made as performance data emerges and user needs change.
Minimum viable product
Working towards a minimum viable product (MVP) in each project allows the team making and operating the product or service to start small, learn fast, and provide value to users as soon as possible. The composition of an MVP and the time required to develop it changes depending on the problem or opportunity at hand.
The practice of defining the MVP and working toward this in a sprint, prevents the practice of shooting for unattainable perfection and storing up work for the sort of far-off big bang releases that sap motivation.
Make something better by degrees.
Content is usually published on bath.ac.uk as a web page. Each web page on bath.ac.uk should meet a clearly defined user need, have a qualified owner and be located in a section of the site that the end-user would expect and where they can find related pages.
We have an expectation of how well a product or service should perform its function(s). We set benchmarks for this performance and then monitor the performance against these benchmarks used a variety of tools and techniques. The insight from that monitoring is used to inform iteration of the product and service and of its benchmarks.
The Digital team provides a number of discernable, tangible products. Examples of our products include the content management software and the analytics software. In some cases we have created the product from scratch or configured a third-party solution to meet the University’s requirements.
The Product Manager is the member of the team responsible for both defining and prioritising the backlog. The product manager holds the vision, champions the users and accepts or rejects deliverables.
In practice, the product owner can be drawn from within the Digital team or be from another team in the university. The qualifications are solid understanding of users, the market, the competition and of future trends, alongside the ability and availability to translate these into actionable insight for the delivery team.
A programme is a series of projects to deliver several - usually sequenced - goals. There are likely to be multiple teams involved over a long period of time.
A project is a collection of tasks sequenced to deliver outputs or outcomes. There are usually a number of objectives and more than one person involved in delivery.
We find prototyping a very useful technique when developing new features, sections or campaigns for the website. Rather than struggling to think in the abstract, a prototype provides something tangible to play with and test our understanding of user needs, how we might meet those user needs, and what sort of effort might be required to develop and run a working version.
Prototyping can be done in many different ways. Sometimes we might prototype on paper or build something functional in the browser. It depends on what the problem is and how much time we have. Access to a prototype is usually only available to the delivery team and the project sponsors, unless it is created for user research purposes.
Someone in the University who creates and/or edits content in the content management system (CMS) is a publisher.
We use ‘releasing’, ‘shipping’ or ‘deploying’ interchangeably when putting something - some code, content or a site - out on the internet.
What someone says they want.
This is a phase where we bring down a product or service with the same level of due diligence that went into its live release. We retire things that have fallen out of use or been superseded, so that they don’t depreciate and cause infrastructure issues or act as a drain on resources
When content is retired, we usually say that it is has been ‘archived’. This means that a copy is still available in the CMS but not live on the site, and that the web address is redirected to replacement or equivalent content or an explanatory message.
A retrospective (or ‘retro’) is a structured meeting held at the end of a sprint or project where the team get to talk about what went well and badly, and agree some actions to improve matters. All delivery team members should be involved and, ideally, stakeholders should be there too.
The discussion points are written up and shared round the wider Digital team for review because there may be transferable learning. In preparing a sprint, the delivery team should review the write-up of the previous sprint’s retrospective.
A roadmap is a high-level plan that describes how the product is likely to develop over time.
Digital tends to produce roadmaps based on goals rather than features. We have a roadmap for each of our products and services that looks up to 12 months ahead, and we review these on a monthly basis.
Agile comes in different flavours; the version Digital uses is based on Scrum. Scrum is a lightweight delivery management framework designed to help small, close-knit teams of people develop complex products.
Using Scrum ensures: our projects have a clear beginning, middle and end; the team doing the delivery is multi-functional and self-organising; management present the team with problems to solve rather than detailed descriptions of how everything is to be delivered; and the project deliverables are released often and little-by-little.
Our website is made up of many pages collected in sections. Each section of bath.ac.uk should have a clear proposition that collects together related user needs. Examples include, /students and /research.
The Digital team provides a number of intangible services. Examples include training in writing for the web and project management.
We may also talk about the services on Bath.ac.uk, which consist of content, tools and transactions. Examples include ‘’report a problem’, ‘book a room’ and ‘who is responsible for education strategy’.
The University of Bath has one main website made up of many pages, organised into sections.
Each project progresses through a series of iterations called sprints. A sprint is a regular, repeating, structured work cycle. Our sprints are a week long (5 days), starting on Tuesday morning and ending on Monday evening.
Every sprint begins with the sprint planning meeting. During the sprint, team members check in with one another at a daily-stand-up to review progress and blockers. Every sprint concludes with a sprint review meeting. Something of value is delivered every day and in every sprint be it code, content or data. Some projects will involve a single sprint, while others may be run over multiple sprints. Multiple sprints may be run back-to-back or over a series of non-consecutive weeks.
In each sprint, we make the backlog visible by putting it on a task board. Team members update the task board continuously throughout the sprint by moving user story cards through columns covering pending/in progress/for testing/for release. A sprint task board can be digital or physically on a wall.
At the start of each sprint, the delivery team gets together with the product owner and reviews what needs to be done and how they will do it.
Each story or requirement on the backlog is reviewed in turn by all the team, gets refined and estimated, and then is sequenced in order of priority.
The sprint team is the collection of individuals mobilised to deliver a sprint goal. In Digital, we think these teams work best when they are cross-functional (they are composed of content, design and development functions), self-facilitating (they organise themselves), consistent (they work together regularly) and co-located (they are working next to each other in the same space).
Wherever possible, we like to have sprint teams made up of Digital people and colleagues from other teams we are working with.
Big, complex projects start with a sprint zero. A sprint zero is a preparation sprint where the working and development environments are prepared, people selected and introduced onto the team, working practices agreed and backlogs prepared.
Stand-ups are very short daily meetings of up to 15 minutes where team members get together to state what they did the previous day, what they will do today and log any problems affecting their ability to deliver that management or other team members could help them with.
Digital has a daily stand-up involving all the team and then each sprint team has its own stand up. Stand-ups tend to happen at the same time every day.
A strategy is a plan of action designed to achieve long-term aim(s). A strategy states and qualifies the aims and by what means they will be attained.
Structured content is a way of organising and describing content components (in a webpage, for example), so that the content can be freed up from a particular format or presentation. Something that is important in the era of multiple channels and devices.
When something - usually a feature or design - is of less than the highest standard or quality.
Our support desk is a central point of contact where any requests for help or work can be sent in to the Digital team and dealt with in a recorded and structured manner. Our support desk has dedicated staff and the ticket trends are reviewed regularly to identify problems and opportunities.
A task is a small, self-contained unit of work within a delivery project, usually with a single objective and allocated to one person.
We use page templates to arrange the features and content on the screen. We have a small number of defined content formats but each of those formats may have more than one template depending on where on our web domain it appears. For example, both the Alumni and the Students section have landing pages that use the same features but different templates.
We do lots of different types of testing on a regular basis across all our products and services to ensure that a product or service meets user needs.
Every release that we do involves testing and each function - development, design and content - has sets of tests that it applies to ensure that what we put on the internet is working as we expect to a consistent set of standards.
Usability is an attribute and a process of making products and services easier for people to use, and matching them more closely to user needs and requirements.
The Digital team often use the term ‘users’ to convey the sense that people are active rather than passive when they are on our website. It’s a catch-all term for publishers, customers and audiences.
User experience (UX) encompasses all aspects of the end-user's interaction with the organisation online, including their satisfaction and trust.
We believe that people are task-orientated when they come to bath.ac.uk or any of our associated digital channels. We believe each feature or content item should meet a defined user need (such as, ‘when does the semester start/finish’ or ‘where can I download the data from this research’).
The Digital team puts user needs above any other needs, meaning that we do what helps the user most, not just what makes our lives easiest. Identifying and researching user needs is part of our everyday work in Digital. We believe that focusing in on user needs provides surer footing on which to build great products and services rather than relying solely on traditional demographics.
Delivery is always improved with user research. In the Digital team there are lots of sound professional opinions, but we always prefer to counsel these opinions with qualitative and quantitative data gained directly from the people using our products and services.
We want research conducted with users to be part of every delivery, especially where the best solution is contested. There are many ways of conducting user research - from page analytics to structured one-to-one interviews. Whichever technique is used, user research should form part of every sprint and the results revisited regularly.
A user story is a short, simple description of a feature told from the perspective of the person who will benefit from it.
A user story briefly explains the person using the feature/content (actor), what the user needs the feature/content for (narrative) and why the user needs it (goal). A user story follows a standard format: As a <type of user>, I want <some goal> so that <some reason>.
The Digital team includes web editors who specialise in particular sections of the website (such as research and student experience) and develop in-depth understanding of user needs from this section and produce and marshall content to meet these needs.
A workstream is a series of programmes undertaken by different teams (some not within Digital) which are required to deliver a strategic goal.
Want to know more about any of these words and phrases, or suggest a clarification or an addition, email firstname.lastname@example.org.