The Agile Fantasy Draft
A solution for assigning work items

June 7th 2016

I'm not an Agile zealot, but I'm also not a complete hater (of which there seem to be many, many nowadays). With that disclaimer out of the way, there's a part of Agile (specifically, Scrum), that I've always been fuzzy on.

The team goes through sprint planning, grooms the work, plays their little poker games, yada yada, and eventually gets to a set of work items that it endeavors to accomplish in the upcoming sprint. Great. Now what? Specifically, how do those work items get into the hands of individual developers? In other words, how does the work get assigned?

The simple solution is "central planning", and though this fundamentally contradicts the self-organization edict of Agile, it is, in my experience, the model which many teams use. The project manager/scrum master/tech lead has some intuition as to which developers would be best suited for which work, and goes about assigning stories/tasks based on that understanding. The end goal here is expedience - rather than a long drawn out discussion, let one person make the judgement call on who is the optimal person to complete a given piece of work.

The problem, of course, is that while this may optimize what's good for the project, it doesn't necessarily satisfy the goals of the individuals. A team may plod along with the "central" model for a few sprints, but it won't be long until some tension and resentment foments: "why does Jane get all the fun UI work?" or "I'm so f-ing sick of working with the accounting module", etc. Basically, we developers all want some degree of autonomy and self-direction, and so we'd like some choice in what we work on.

And this of course is why one of the pillars of Agile is self-organization. The problem is that there's no good, thoughtfully specified process for assigning work items, and so teams can instead end up adopting what amounts to a Hunger Games-style free-for-all. Planning is over, the work is ready, the horn blows, and the team rushes to their laptops to grab the work they want. This is probably an exaggeration - maybe instead there's a post-planning discussion where developers make dispassionate arguments as to why they should take the fun, new feature and someone else would be better off making a small enhancement to the registration form. In any case, the same tension and resentment can build, but this time directed at each other rather than the lead.

A solution that we've stumbled on (and have now used on a few projects) is the fantasy draft. At the risk of explaining the obvious, here's how it works:

There are subtle refinements to this process, of course. We've instituted a clock (2 minutes per pick!), a looping scheme (2nd round goes in reverse from last pick to first), and a carry-over rule (work unfinished in a previous sprint is automatically carried over to the same developer). We've also considered "franchise players" and allowed draft pick trades.

In general, it works pretty well, and, if nothing else, is a lot of fun. Draft day comes with all the frivolity that you'd expect from a fantasy draft - someone wasted their first round pick on a trivial user story, someone couldn't pick in time, etc.

Beyond the fun though, the draft system has some other nice qualities, most notably fairness. People are in control of their own destinies. If they get the shaft this sprint with a shitty draft pick, well, next sprint they'll likely do better. It also distributes the "fun" work more equally. If the UI is the most desirable tier to work in, with the draft system it's more likely that most people will get an opportunity to get their hands in there in some capacity. This might come at the price of efficiency, but definitely aids maintainability and knowledge dispersion.

There are, of course, some downsides. The most obvious is that it gives no preference to seniority or capability. That complex integration piece can be picked up by the a junior UI developer if he so chooses. On the flip side, the most senior developer might get stuck writing the 93rd login form of their career (and be none too excited about it). As a "senior"-type person, admittedly, this can suck.

Anyway, I write this less to advocate the fantasy draft as the model that you should use, but more as a way to find out what others do on their teams. How is work assigned? What are the pros and cons?

Thanks to Handerson Gomes for the pictures!

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (4)
June 07, 2016
I absolutely agree that autonomy and responsibility needs to be pushed down as much as possible. I like to think of it as, "I am training my underlings to do my job"
June 08, 2016
@Kate - thanks for the comment!

Also, there was a comment on Reddit about a pull-style/Kanban approach to assigning work - i.e. when you're done with one task, pick another from a pile. I failed to mention this in the post, but it's a very useful approach with some different pros/cons.
June 16, 2016
Interestingly, the teams where I work never seem to have this problem. Perhaps it is because the teams tend to be small (3 to 7 developers) and have diverse skillsets (some UI folks, some QA-turned-developer, some senior developers, some new people), but I tend to see that people just speak up about what tasks they want to take, and there is almost never contention about it.
June 23, 2016
@Michael - thanks for the comment. Good point - if a simple conversation suffices, that's definitely the best bet. In probably a lot of cases (like you mentioned, with smaller teams or teams where people have specialized skills), this works fine. When teams get bigger or when there ratio of "interesting" work to "boring" work is low, then I've definitely seen value in a "draft" process.