As you may recall from the Fogbugz chapter, I mentioned creating “filters” to view your tasks per sprint. This tutorial is all about those sprints. A sprint is a set of tasks you plan to get done in a given period of time. The goal behind sprints is to get to a point where each week you accomplish what you planned. That said, you will overestimate what you can get done in the beginning. That’s fine. Move the remaining tasks to the next week’s sprint, maybe add a few new tasks, but make the sprint size smaller than the previous week’s. Sprints can be of any length. Ours are one week at a time, and that’s just how we recommend you do it. For larger applications, such as video games, a longer sprint length may make sense, but that’s not the sort of application these tutorials are written for.

Let’s talk about the value of sprints. Sprints establish predictable rhythm of execution through which you know when to expect results. The type of applications we do (to begin with at least) are medium-small applications that capture the precise minimal viable product (“MVP”) you need. Therefore, we can do our sprints in increments of a week at a time, rather than larger increments common to desktop applications of yesteryear. This insures that non-technical stakeholders feel the pace at which developers are going from the start. This allows everyone to gauge progress, and accordingly feel comfortable with the process every step of the way.

At FaceySpacey, starting on Thursday until Monday morning, our clients in conjunction with our dedicated testers test the application. By the way, teams without dedicated testers are wasting your money by having highly expensive engineers be solely responsible for testing, and waste your time by putting the responsibility completely on you, somebody just getting acquainted with the process of software development. The final thing we do here is we do not move to new features until the current features work perfectly. The reason is simple: fixing bugs later when coders are less familiar with the code at hand takes many times longer to fix than fixing it right when they first made it. Therefore, if you don’t complete tasks in the current sprint, find new related tasks, or find lots of bugs, those tasks should go into the next sprint before adding new distinct features.

Back go Fogbugz. In Fogbugz you will take all the tasks from the “product backlog” previously described and assign them to what Fogbugz calls “milestones,” which we use to represent sprints. Basically you’ll assign the first tasks you think should be done to the first milestone/sprint, and then the next set of tasks to the second sprint, and so on. You’ll do that until all the tasks in the entire product backlog are assigned to milestones. Make sure to note that most likely you’ll end up with more sprints than you originally planned as things take longer than you initially thought, and you find your developers working on a task in a following sprint that was planned to be done in the previous one. That’s fine. What we’re talking about here is getting an initial birds-eye-overview of what will follow in the development process. Specifically, you’re pinpointing the order with which you should do things. That order will change, and you’ll alter your sprints as you go, but give yourself and your team an idea of how you imagine things going from the start.

When you build these sprint filters that lists all the Fogbugz tasks (which by the way are called “cases” in Fogbugz), you’ll group the tasks by OPEN, RESOLVED or CLOSED rather than by Area. These are called “statuses” fyi. Throughout the week you’ll see tasks move between these 3 groups from open, to resolved to closed. In Fogbugz, this is like a vertical Kanban chart. If you don’t know what a Kanban chart is, check this out: http://www.infoq.com/articles/agile-kanban-boards . It’s a way to visualize tasks go through their sequential stages from being started to completed. At FaceySpacey we find this to be a key motivational tool and tool to help us focus.

Back to how to build these sprint filters. Now, since tasks aren’t grouped by area anymore, you will need to add a column with the area so you know what part of the application the task has to do with. If your team is using the time tracking tools (which are used to generate graphs that predict when things will be completed), you’ll also want to add a column that states the time elapsed on the task. This requires that your developers record how long they work on each task. It takes a lot of discipline within a team to do this. Luckily since you’ve been using the sub-tasking feature previously mentioned, a developer can simply state how long the overall task took, like at the end of the week. Fogbugz has great algorithms to make estimates on when things will be done based on past performance. So any data here provided your developers is better than none and enough for Fogbugz to produce some pretty--and useful--graphs.

The last 2 columns to add to this filter are one for which developer each task is assigned to, and an order column provided by the “backlog” plugin. Basically you can set the order developers should do each task.

Fogbugz offers a lot of functionality, but I find the most important functionality is just how flexible its filter system is in how it allows you to re-organize the same tasks in as many different views as you want. For example, I often list tasks in a filter that groups them by developer so I can quickly see what each developer has.

Another trick I intentionally didn’t mention above is I actually create fake users for “RESOLVED” and “SPRINT BACKLOG” in order to make the vertical Kanban chart. The reason is this: the “OPEN” status is embodied by being assigned to a developer. So therefore the groups in the filter described above have the names of developers at the top, and then when each developer resolves a task the task all goes to the same “RESOLVED” group. Before a developer starts working on a task, the task is stored in the “SPRINT BACKLOG” group. And of course after the task/case is tested, it’s sent to the CLOSED group. So the trick here is that we’re user real and fake users to make the groups, and building the filter so that users are chosen for how to group the tasks. The result is that throughout the week you can watch the tasks move from the top of the page to the bottom as they go from each group to the next, and at the top there is little mini groups for each specific developer, rather than all the tasks grouped together. You could add a “developer” column to the task list, but I find visually this grouping very effective.