Welcome to the third installment of The ELTjam Lexicon of ELT in the Digital Age. You can read more about the series here and see the full list of terms we plan to cover here. This week, we begin the ‘B’s.
Backlog and backlog grooming
The term backlog grooming will never not make me laugh.
In order to get our heads around these two concepts, we need to delve into the world of product features. When I worked in house at a large ELT publisher, one of the things we would need to do when we took a new publishing project for budget approval was draw up a list of features and benefits. The features were the things that a product ‘did’ – that is, what characterised it. The benefits were how these features would add value to our customers. For example, an oft-cited feature of adult general English coursebooks is that they’re ‘teachable off the page’. The corresponding benefit is that teachers don’t have to spend any time prepping their lessons, which is valuable to them. When you’re creating a print-focused publishing product, you tend to get all of your features decided at the start, and then as you create the product, you make sure that those features are apparent to the user. For example, if you’re going to claim that your course is teachable off the page, then the authors need to write with that in mind, the designers need to design with that in mind, and the editors need to check that it’s actually true.
Teams who work according to Agile development practices approach features differently. One of the key roles of a Product Manager is to decide which features the users of a product will find valuable. These features are usually expressed as user stories – sentences that explain what a user might want to do and to what end. For example, a user story for a vocabulary app might be something like ‘As a user, I would like to select the level of vocabulary that is appropriate for me so that I am given the right amount of challenge’. To go back to the print example, that user story might be ‘As a teacher, I would like to be able to teach the lesson using nothing other than the information given on the page, so that I don’t have to prepare my lesson ahead of time’.
Here’s a key difference between how print publishing and digital product development work: in print publishing, you line up all of your features at the start of the project and then create the product according to them; in a digital product, you begin by putting all of your proposed features into the product backlog and then decide which of them you’re going to implement as you go along. You can think of the backlog as a kind of unsorted inbox – it’s where all of the features live before we decide what to do with them. At the start of each development sprint – the two-week period during which the team aims to build and deliver some working software that customers can actually use – the team goes through the backlog and decides which features it’s going to try to build during the upcoming sprint. Those features can be prioritised according to a number of criteria, but what’s best for the business is usually the driving force. During these discussions, certain features will be prioritised, others will be de-prioritised or removed altogether, user stories will be tweaked based on new information, and estimates for the amount of effort required to deliver the feature will be pinned down. This whole process is known as backlog grooming and probably sounds much less interesting than the name might have suggested.
What are the advantages of this approach? Well it comes down to the alleged value of the Agile approach in general – that by prioritising the features that your users truly value, you’ll create something that they really want and that truly meets their (ever-evolving) needs. Could it work in print publishing? That’s a much harder question to answer. We tried to tackle this to some extent in this post, originally from 2013: Applying the Pareto Principle to ELT Publishing.
A useful weapon in your gamification arsenal, badges are used in an educational context as a reward system tied to achievements. For example, Khan Academy lists six types of badges that you can earn. These range from Meteorite badges, which are ‘common and easy to earn when just getting started’ through to Black Hole badges, which ‘are legendary and unknown’ – the ‘rarest Khan Academy awards’. A good example of the use of badges in an ELT context is Newsmart, a product that we work on here at ELTjam. Newsmart users can earn badges for achieving certain things within the product. For example, if you earn 200 points by correctly completing exercises, you unlock the Rising Star badge:
You can also win badges for engaging with the product, for example by commenting on articles in English.
When we were developing Newsmart, the product team were very keen on using badges, and I actually pushed back. I was convinced that the target audience for the product – business people looking to improve their English for work – would find them infantile. It turns out I was wrong. Feedback from users was overwhelmingly positive. Sometimes it’s nice to be proved wrong. Perhaps I could have won the Naysayer badge in return?
This one’s a potential game-changer if you’re an ELT project manager.
ELT publishing has traditionally worked with large batches of content. Let’s imagine that you’re working on a six-level coursebook series. You could break that down into lots of different batch permutations, for example:
- One batch = all components for one level (e.g. Student’s Book, Workbook, Teacher’s Book, etc.)
- One batch = one component from one level (e.g. Student’s Book)
- One batch = one unit from one component from one level (e.g. one unit from the Student’s Book)
Authors and editors traditionally work using permutation three above: the author team writes a unit, and while the editorial team look at it, they write the next unit, etc. However, colleagues in Production often want to work using permutation 2 above – that is, they won’t accept the content from the editorial teams in small batches; they want the whole lot in one go. In fact, up until recently batching was something of a dirty word in ELT publishing, although I gather that the pressures of tightened schedules are changing that. In any case, what is traditionally handed over to Production is an entire manuscript, and from that point onwards the batch size tends to be one whole component from one level.
It doesn’t take much imagination to figure out the kinds of things that can go wrong once you’re working with batch sizes that large; however, this example from Eric Ries, author of The Lean Startup, explains it better than I ever could:
In the book Lean Thinking, James Womack and Daniel Jones recount a story of stuffing newsletters into envelopes with the assistance of one of the author’s two young children. Every envelope had to be addressed, stamped, filled with a letter, and sealed. The daughters, age six and nine, knew how they should go about completing the project: “Daddy, first you should fold all of the newsletters. Then you should attach the seal. Then you should put on the stamps.” Their father wanted to do it the counter intuitive way: complete each envelope one at a time. They told him “that wouldn’t be efficient!” So he and his daughters each took half the envelopes and competed to see who would finish first.
The father won the race, and not just because he is an adult.
The one envelope at a time approach is a faster way of getting the job done even though it seems inefficient.
Ries goes on to explain several reasons why that might be the case, but this one struck me as the most pertinent:
Imagine that the letters didn’t fit in the envelopes. With the large-batch approach, we wouldn’t find that out until nearly the end. With small batches, we’d know almost immediately.
Despite our best efforts, editors always spot problems with a book once it’s gone into production. If those problems affect every unit, or every example of a particular activity type, then fixing them all becomes a massive task; the error is everywhere and has to be fixed everywhere. With a smaller batch size, the error could have been spotted earlier, fixed in a smaller number of places, and then systems put in place to ensure it didn’t happen again.
What might this mean for print publishing? Well it might be a case for working more like this (excuse the over-simplification):
- Author and editor finalise a unit.
- Unit is handed over to Production.
- Back and forth between designers and editors until unit is signed off.
- Repeat steps 1–3 for a new unit.
Experienced editorial project managers will look at that approach and assume that it must be much less efficient than the way we currently do things. For one, what are the author team up to while steps 2 and 3 are going on? Just sitting around twiddling their thumbs? That’s because what has always been prized in ELT publishing is resource efficiency rather then flow efficiency. We’ll be exploring those two concepts, and what all of this might mean for the creation of digital ELT products, in later posts.
1. In a waterfall-style workflow for an ELT digital publishing project – which has stayed the same in many publishers since CD-ROMs were flavour of the month – the stage after Alpha. It’s basically second proofs for a digital product. As many editors will tell you, you’ll usually have Beta 1, Beta 2, Beta 3, Beta 4, etc.
2. In general software development, the final test release of a working piece of software, usually to a limited number of users, before general release to all users; a tactic underemployed by ELT publishers.
Coming next in The ELTjam Lexicon of ELT in the Digital Age: big data, bottom-up, build-measure-learn, business model canvas, Busuu
Join our mailing list
Get new ELTjam posts & updates straight to your inbox