If, like me, you work for corporate clients a lot, chances are that you’ll be part of a chatbot scrum team. And that you’ll work in sprints: fixed periods of time in which the team commits to finishing a pre-planned package of work.
Traditionally, IT teams work in two-week sprints. That’s usually enough to develop, test and deploy one or more software features. But what if you’re in a chatbot or conversation scrum team? Is a two-week sprint a relevant period of time for what we do? Is a bot content cycle really two weeks long?
Fixed publication windows
As a tech writer in aviation, I worked in 4-week-cycles. That is: for regular, non-urgent content, my team had a fixed publication window of one day each month. It coincided with what’s known as the AIRAC-date, the one date where changes in aviation systems and procedures become effective, world-wide.
Reason for that: you don’t want to be mid-flight on a long haul flight and discover the airport you’re heading too has all of a sudden changed the arrival route, while your board computer hasn’t been updated yet.
Four weeks have always felt like a very natural cycle for regular content to me. My team worked with a XML-based content management system, which resembles our chatbot platform systems, in that it required the content to be collected, assembled and published.
Research
Four weeks was long enough to do research on the domain at hand and to consult with my SME’s. Aviation projects, and corporate projects in general can be complex. And as a tech writer, it was of course my responsibility to make sure that procedures were clear, correct and unambiguous. Something that I couldn’t do alone and required a lot of co-ordination with developers, procedure designers and air traffic controllers. I guess that of all my time as a tech writer, I spent perhaps 20% writing, and easily 60 to 70% on research and co-ordination.
Content planning and review
Four weeks also allowed me to plan re-use and coordinate with my 8 fellow tech writers. To draft initial copy and to finalize the reviews (and their iterations) before handing it over to the change owner for official hand-off. And after that, assemble the actual publication, proofreading it, making the necessary corrections, rebuild it, in some cases even send it to the publisher (redundancy requires some information in aviation to be available on paper).
Weekly intake
The intake of change requests, on the other hand, was much more frequent. From urgent messages, which would be sent out continuously throughout the day, to weekly intakes of what would now be called epics, which would be distributed amongst our writers in a weekly planning meeting (mind you, this was way before scrum even was a thing).
So I guess we didn’t really have sprints in terms of a fixed series of time-boxes. Start could be anytime, as long as you only publish in the monthly publication window.
So… how long should a content sprint be?
You know? Agile doesn’t prescribe anything. The Agile manifesto doesn’t contain any rules (and Agile is not scrum, but let’s keep that for another article ? ) Agile promotes an empirical, pragmatic and objectively measurable take on how your organisation performs to the best of its ability. In terms of scrum, a sprint should be long enough to produce results, and short enough to mitigate risk. If it’s longer than a month, that’s OK too, it’s just not scrum anymore.
Yet, when organisations adopt scrum, they often copy someone else’s model, including, in many cases, the default two-week sprint. This might be OK for IT teams. But it’s a possible trap for other teams. Because a two-week sprint is fine for building most software (that’s what scrum was created for). But it might not necessarily reflect the creation and publication cycle that feels most effortless for conversational teams. Leading to artificial boundaries and deadlines, and following-the-rules-because-we-have-the-rules.
Don’t do scrum. Do what makes sense.
In my tech writing team, we found a rhythm and a way of working that worked for us. Not perfect of course, but it was consistent, repeatable and most of all: it was evidence based. Scrum didn’t exist, no-one told us how to design our process, so we created it ourselves. And because we stuck to it (quite obsessively) and refined it, it worked.
So here’s an invitation: don’t do scrum ? Be agile. And do what makes sense.
Recent Comments