-
Notifications
You must be signed in to change notification settings - Fork 6
3. Project Management
At Daft Labs we more or less follow the scrum agile implementation, but we take a pragmatic rather than dogmatic approach to our process. In essence, figure out what works instead of rigidly following scrum guidelines. Change things if necessary, and when variables like team size or clients change, review the process to find way to be more efficient.
Sprint length is typically relative to the billing cycle of clients. This approach gives the project owner a good indication of what exactly they are paying for each cycle. All development revolves around the project management system. The majority of Daft Labs’ projects use Pivotal Tracker. Other examples of similar applications include JIRA and Trello. The main page or dashboard will have a kanban of user stories in various states of progress. Stories are tasks to be completed for a project. There are three main types of stories:
Features are stories that provide business value to a project. A features’ value is measured in points of difficulty, instead of estimated hours to completion.
A trivial task without any risks, such as changing some text or adjusting a color.
A task that is beyond trivial, but something you have done before in the past, so that you know exactly what code needs to be written. The risks to unforeseen complications should be very low.
The task is still fairly straight forward, but may, for example, require touching more than one area of the project. The chance for regressions is higher than 1 and 0 point stories, so tests and small amounts of refactoring may be required.
The task is medium or greater difficulty, but the scope is still thoroughly defined. Research may be required before development begins, which may inadvertently increase the complexity of the task as the developer learns more about what is needed for the implementation. Tests will be required to ensure correct functionality, and to catch regressions from other related stories. If refactoring isn’t utilized, then technical debt will occur, which will slow development team velocity, as the application becomes more difficult to work with.
A difficult story with one or many unknowns. Typically a 5 point story is a multi day project with a high risk to exceed initial estimated time. Research, refactoring, testing, and possibly prototyping are requirements for success. In most cases 5 point stories should be broken down into several 1 - 2 point stories.
Basically the equivalent of “sudo make large and complex application component”. 8 point stories are the starting point to writing down project priorities, but they should be broken down into more manageable stories before being put into the current or backlog boards.
Points will roughly translate to development hours. 1 - 3 point stories typically take less than a day, and 5 - 8 points are multi day stories. Since points are a relative value they have a few advantages compared to directly estimating using hours. Once one or more sprints have been completed, the team’s velocity, or speed at which a team can finish stories, will be automatically calculated by Pivotal Tracker. This velocity will be used as a metric to automatically plan future sprints.
The more diligent you are, as a developer, at accurately estimating points and making adjustments to things that weren’t successful during a sprint, the more accurate future sprint estimating becomes.
Sometimes, during large pushes of development, additional developers will be added to a project to increase the velocity of a sprint for time sensitive features. During the sprint the velocity will rise higher than normal levels due to the increase in development power, so when the team size returns to a normal level, the velocity should be artificially lowered to compensate for accurate future planning.
In general, labels can be added for a variety of reasons and new label names should be invented all of the time. To facilitate project management, some specific labels should be used consistently across projects and have specific meanings:
needs-design; needs-estimate; needs-breaking-down;
The story needs attention from the project's lead designer or project anchor. Project Anchors should use needs-breaking-down and needs-design labels on stories liberally in cases where stories are ill-defined or ill-scoped.
needs-pm
This story needs a project manager or product owner's attention — there is a question about requirements, cost, or feasibility. Please add a comment indicating the specific action or question requested.
blocked
This story is blocked on progress by one or more factors. Please add a comment indicating blocking factors. If the story depends on another story, please state this and link to that story in a comment.
urgent
This story is time sensitive. Please add a comment indicating the deadline and reason for urgency.
Bugs are known issues with the project. Bugs are not worth points, because they technically don’t provide value to a project. They restore the project from negative business value to expected business value. Teams that are lax in following best practices and processes will find that bug fixing may take up the majority of their time, and their velocity will suffer. On the other hand, a team that can define stories that are small, easily understood, discussed before development begins, verifiable by the project owner or proxy, and covered with automated tests will find they are able to limit the amount of bugs that occur. We should always strive for the latter.
The zero defect rule is followed at Daft Labs. This means that all bugs should appear at the top of the backlog and be finished before feature stories are worked on. Studies have shown that the longer you wait to fix a bug the more expensive the bug becomes.
Chores are stories that are needed, but don’t provide business value. Refactoring, tidying, and operations tasks typically fall into this category. These types of tasks are necessary for successful software development, but it’s important to make the distinction that they don’t actually add new progress to the project. Points are about how efficient a team is at adding progress to a project, not how much total work they do within a sprint.
This is where stories are born. The project manager will sit down with the project owner to go over what the project requirements are. Stories are created in a free form matter. Any member of the team can create stories here.
Here the project manager and and project owner will discuss what the priorities will be for the sprint, and possibly future sprints. Any stories placed in the backlog that are scheduled beyond a month will most likely end being changed as priorities and requirements change. So only the near future is really super important to fill. While the project owner decides what he wants the development team to work on, only the development team can estimate story points and their complexity. This grooming process of estimating and breaking down stories into smaller pieces is important for successful sprints and accurate expectations.
These are the stories that are currently being worked on by developers during the sprint. A developer will take the top story from the backlog when starting a new story.
The story has been defined and placed in the icebox for further discussion and estimation.
The story has been broken down into multiple more manageable size stories if needed. One or more developer has gone through each story and assigned the estimate point value.
The developer has taken the story out of the backlog and began the work to complete the story.
The initial phase of development has been completed by the developer. It is now ready for analysis by the continuous integration system, and code review by 1 or more other developers.
Code review and analysis is completed, and the change has been deployed to either a staging or production environment where the project owner can review the story.
The project owner has reviewed the story and signed off on its completeness.
The project owner has reviewed the story and rejected its completeness. The story is now in a equivalent state of Estimated, and the process continues again from there.
Pivotal Tracker Getting Started