Saturday, 21 March 2015

Scrum - Part IX: Task and release pinning

Time to go back to Agile/Scrum. The last post talked about long-term planning of projects that cross several teams and sprints, however there are even smaller facets to Scrum scheduling.

Often, we get into a situation where people - customers, other development groups, execs (yes, despite what you might think, they are all people!) - do not need a particular feature next sprint, or tomorrow. They just need a commitment that a feature will be there by next February.

When we mix and match that into Agile backlog, a dilemma appears. These features need not be at the top. However, if we stick them into the middle of the list, they will permanently remain there; higher priority stuff will jump above. We need a way to ensure the tasks get done at a certain point in the future, and classic sprint planning won't cut it all the way.

Wait, why do we need to commit for next February?

Thanks for interrupting - indeed, I'm racing too fast. Let's give a few examples:

Renewal. Customer's renewal is coming up in a few months. They do not need a specific feature right now, but they are adamant on having it by the time of the renewal: to see commitment from us, and/or facilitate their internal migration.

Cross-team dependency. Recall my example from the last post. We had several teams, and one of them, system QA, was not involved in the project a couple of sprints. However, when Sprint 44 comes, it's critical that they'll have time to work on our feature and understand well what needs to be done.

Marketing. Analyst review is scheduled for date X, and we need to run a set of activities, such as getting demo environment in place, tidying up specific issues from last review etc.

There's more: upcoming hardware upgrade from vendor which will require performance testing, exec reviews, release regression testing etc.
These cases might or might not be frequent depending on what your team does, and whether the product is well established, but hopefully by now we agree that they exist.

Ok, how do we deal with future commits?

One approach is pinning a task to a future sprint. Taking the system QA team as a case in point; even though they are currently in Sprint 41, nothing prevents pre-populating a few tasks in Sprint 44, such as end-to-end testing of telemetry.

Of course, reality may always change. In fact, if we go back to the previous post, it did change - the feature got delayed for valid reasons, and it couldn't have been tested before Sprint 45. This is fine; having the telemetry test in there was just a declaration of intent and reminder-slash-placeholder - not a commitment.

In the same spirit, our QA group might become overloaded in Sprint 44, and even despite the dependency will have to push back the telemetry test. This is also fine; at least having the placeholder there will remind us that this choice will affect other groups who need to be informed.

By the way, QA is just an example; I realise that many Scrum teams incorporate the QA function. If this specific case bothers you, feel free to swap it with front-end/analytics/back-end/DB/UX/"anything-else-that-comes-to-mind" team.

But surely we cannot pre-plan sprints in next February?

Yep, this technique works ok for dependencies in projects round the corner, but does not cover the renewal, roadmap or marketing examples. Nobody will relish seeing thirty future sprints in their backlog; just the thought of managing and staring that is a migraine trigger.

A more benign technique is tagging future tasks. Let's say that a marquee customer is switching to Mac OS X next March. We do not have a strategic requirement to support this OS, but we absolutely have to add it for them, otherwise there will be disaster and chaos.

We could put this at the top of our backlog, but we won't cover ourselves in glory by supporting the OS today. It will just gather dust until next March - we could have spent our cycles for something that people need here and now.
So, tagging OS X support with something like "February 2016" will serve as a reminder. (Or we could tag with whatever version id we plan to release in Feb-16, e.g. Ver 6.0)

None of this is revolutionary by any stretch of imagination; just a few small techniques to make sprints more manageable.

Origins of species sprints

Perhaps the only remaining point is a gradual evolution of tasks. This is also called more formally backlog grooming; the idea is that as we get closer to starting on a user story, we zoom in on it, and derive better estimates.

The reason I brought it up here is that with tasks pre-planned in the future, we know a bit better what should be groomed/evolved/designed (circle out your favourite verb).

In many cases, this evolution is gradual and very low-key. Let's take our system QA task as an example; it is currently pinned to Sprint 44, and we are at Sprint 41.
Current Sprint Target Sprint Estimate What we know
41 44 One week We need to verify and potentially automate a few global metrics
42 44 Six working days: three days - manual, three days - automation There are two global reports, both are automatable, and we can use some of our existing UI scraping code
43 45 Five working days: manual testing of per-client and per-codec reports(half day each), augment UI scraping code (one day), write automation test cases (two days), prepare test exit report and retest bug fixes (one day) Full list of use cases, low-level design of automation code, and test plan draft.

In case you're wondering why there are days instead of story points, have a look at this post.
Also, the usage of one week versus five days is completely intentional. Coarse units reflect poor understanding of a task; 160 working hours and one person-month mean the same thing in theory, but in practice people read them quite differently.
Coming back to the table - in each sprint the understanding of testing to be done was gradually evolved. In Sprint 41 we had a placeholder that assisted future capacity planning. By the time Sprint 43 rolled in, we knew fairly well what we have on our plate. (If you're asking who provided the numbers, have a look here).

Just to make things clear: there are more focussed and faster planning techniques - we do not always have the luxury of having tasks set up three sprints in advance. One of them is a planning spike, and I'll cover it in a future post.

No comments :

Post a Comment