-
Notifications
You must be signed in to change notification settings - Fork 2
How We Use SCRUM
Sprints are units of time used to organize development in SCRUM. Generally they last two weeks each, and at the beginning of every sprint, the goals of the sprint are planned by the team. The idea is to have a working product by the end of every sprint, and build up the final product incrementally.
On Github/Zenhub, we are going to use milestones to help us keep track of our Sprints. Milestones can have deadlines, so we can set them to the deadlines of our Sprints, and label issues being taken on this sprint with them. Zenhub can use milestones to calculate how productive we have been, actually, so they can be useful in measuring our progress.
In SCRUM, issues are broken up into one of these four categories. On ZenHub, we use labels to indicate which of these an issue is acting as. They are designed to be mutually exclusive.
Epics are groups of stories, which provide an extra level of organization. They are useful when it feels like a group of stories could be considered one big story, but also feel like they should be broken up into smaller pieces.
Stories are essentially a feature request. They are used to indicate a goal that we have for our program, from a black-box perspective. That is, when we write the story, we are solely thinking about what we want to have happen, and leaving the how to whoever starts writing the tasks for that project.
Tasks exist to break stories down into individual, concrete jobs that can be done one at a time to meet the requirements of their parent story. These can be as small as 'email so and so about this thing we gotta do'. The more precise and concrete they are, the better. I've found a common pitfall to tasks is that sometimes it would take less time to accomplish a task than it would to actually write out a task for it. In these cases it is largely up to the team to decide what makes sense. Sometimes it's better to just group whatever you're doing with the task it is most relevant to.
SCRUM does not officially cover what to do for bugs, because SCRUM is not solely a Computer Science practice. I find that Bugs should be treated like stories, from my experience. After all, a bug report is ultimately a feature request anyways-- Just that the feature being requested is for something to work like it is supposed to. I would encourage developers to create tasks to track their progress on a bug. Since bugs, by their nature, will take research and trial and error to fix them, tasks will be difficult to plan ahead of time.
These other labels will make it easier to organize and understand our issues.
These two labels show that there won't be a source code change associated with the completion of these tasks. In addition, I find that these are very useful if you're making changes to your code locally to try and fix a bug, but aren't certain that the test will work. If it works, you can create another non-research task to implement those changes, or if it doesn't, just note the results when you close the task. The documentation task in particular refers to tasks that involve documenting things, be it in the readme, wiki or otherwise.
These are exactly what they sound like-- They can be used to show the order we would prefer to get things done in, if we're not going to have time for everything. It can encourage developers who are looking for something to do to try making progress towards the high priority issues before anything else, so the team stays on track to finish the sprint.
Story points are arbitrary numbers that, relative to one another, indicate about how long a task or story will take to complete. Each unit could be thought of as about an hour, give or take 30 minutes, but the points are much more powerful once a few sprints have gone by, and the team can start to expect a number of points to get done every time. In reality what a story point means for one team could be very different than it is for another team.
On ZenHub, we have a feature to assign story points to our tasks. We will assign stories points to guess how long they will take, but also assign tasks points. This does end up being redundant and skew the data a bit, but we have no choice if we want to both estimate our time as well as record it incrementally as we go.
Story points are important to estimate and update as you develop, because it is the primary method through which we quantify our productivity on the project. Think of recording story points like a hand-wavy version of clocking hours at a job.