The Project Board (and how not to screw it up)

Kanban board, scrum board, project board - whatever you call it, will be vital to both your project organization this semester and your grade. Its purpose is to track all of your requirements (user stories) and tasks as they are created, fleshed out, assigned, completed, and closed. The tool that we’re using for our board is called Zenhub.

Stories and Tasks

Each item on the project board will be either a User Story or a Task. This is indicated by applying the appropriate label to the item. There should be no items anywhere on the board that are not labeled as one or the other.

User Stories

User Stories are requirements that address a particular function desired by the users of the software. They follow a simple pattern:

As a <type of user> I want to <do some thing> so that I can <achieve some testable goal>

Note that the type of user should not be “user” (that tells us nothing about why you are using the program), and that the goal must be testable. Any story that cannot be tested by the type of user that story is for is not a valid story. The tests for a story should be put in the definition section of that item.

Tasks

Tasks are the steps required for the developers to implement the User Stories. A user story with no tasks can’t be implemented, and a task with no story makes no sense - all tasks should be supporting a requirement. Tasks should support one and only one User Story; while there are instances where one task is necessary to more than one story, in our organization we will simplify the relationships by assigning it to only one of those stories (your team can choose which seems the most appropriate - usually the one being worked on first). A task must also be testable, but it is testable by the developers, rather than by the type of user for whom it’s associated story is written. The tests for a task should be put in the definition section of that item.

Pipelines

A scrum board consists of multiple pipelines. The purpose of the pipelines is to capture the state of your stories and tasks. Each organization determines the number and naming of those pipelines for projects, since there may be different needs in each organization, but internally, all boards should be the same. This eliminates the need to guess what the meaning of each state is; once you understand the process for your organization, you should be able to read the project board for any project and gain an accurate understanding of its state.

For our organization, there are six pipelines. These pipelines are named Backlog, Planned, In Progress, Testing, Complete, and Closed. Stories and tasks will (generally) move from left to right through these pipelines as they progress. They should not “skip” stages as they move - for example, you should not move from In Progress right to Complete without stopping in testing along the way.

Backlog

The backlog contains any unfinished story or task that is not planned or in progress for the current sprint. While they are in backlog, it’s OK if the stories and tasks still need work; they should be entered after the initial brainstorming process, or as new ideas arise during development, and they may not be fully fleshed out, or have tests, or be a bit vague. They may not be broken down into tasks, and any tasks may not yet have their tests defined. Backlog is a big pile of possibility.

Planned

At the beginning of each sprint (or better, at the end of the previous sprint), you and your project managers will select the set of stories to be developed during that sprint. These stories (and their associated tasks) will then be moved by the PM from the Backlog into the Planned pipeline. This is the point at which your stories need to be refined; they should be specific, have acceptance tests, and have one or more tasks associated with them. The tasks at this point should also be specific, and have their task tests defined. The User Stories should move with their tasks - it is incorrect to have a task associated with a story be in Backlog, if the story is Planned.

In Progress

Once a task has been assigned to a developer, the task and the associated story should move into In Progress. This indicates that someone is actively working on that story and task. Note that not all the tasks need to move along with the story; it’s OK to have some tasks for a story in planned and some in later stages.

Testing

Once a task has been completed by the developer, it moves to testing. While in this queue, the developer will execute the task tests (and may want to ask another developer to run them as well as a cross check). Once all the tests for a User Story have passed testing, the User Story will move into testing, and the acceptance tests will be run.

Complete

Once the tests have passed, the task or user story moves to complete. It will then be reviewed by the Project Manager for final approval before moving to closed. Once a story has moved to complete, the story’s branch can be merged back into master for the sprint release.

Closed

Once the Project Manager has reviewed the task or story for completeness, it will move to closed, and the process is complete. No tasks should move to closed without PM review and approval. Moving them to closed without that approval can result in the person who moved it being marked as unprepared in the proceeding team meeting.

Project Board FAQ

This is one area in which the artificial nature of the classroom intrudes. There are a few different ways to address this. One is to have those tasks exist outside of the board, and this is frequently the case in agile, where the board is supposed to be all about the code. Unfortunately, this doesn’t give us anything to grade. A second way is to have them be tasks associated with a user story that will actually be coded in sprint 2, but that also creates issues of not being able to make it all the way through the process in sprint 1, closing out tasks and stories. A third option is “make up bad stories”. In order to give you experience moving through the pipelines, we can create stories for invalid users like “As a project investor, I want to see a prototype of the screens before investing so I can verify that the project looks promising”. We will use approach three, which has the least impact on the overall SDLC and normalizing grading.

What if a task supports multiple stories?

While this can potentially happen (especially in areas like API design where one set of endpoints may support multiple actions) in order to reduce complexity for these projects, just pick the first of the stories being developed, and attach it to that.

What if a story/task doesn’t get finished during a sprint?

If that happens, tag the story and tasks with BOTH the sprint it was started, and each subsequent sprint until it is complete. This will help project managers determine areas where you may be running into trouble.

What if a story or task turns out to be impossible?

Especially when you are experimenting with new (or new to you) technology, it is possible that something you planned turns out not to be feasible to implement. Those stories should have comments outlining what was done and why it is not feasible, and be moved back to the backlog - it’s always possible that future advances make them feasible!