We have run a lot of successful projects with Trello following a rough Kanban-style approach that focuses on continuous delivery. However, as we have taken on projects that involve more people and have longer timelines, the process and tooling left us wanting more.
Retrospective
We continually review how we develop software so that tomorrow we can be better than yesterday. In this vein, we have noticed that on projects with longer timelines and larger teams that using our Trello-based process there was plenty of room for improvement. This was partly a tooling issue, but also partly a process issue.
This process starts with a list of lists, ordered from idea to delivery, that looks something like:
- Backlog - defined issues not yet in development
- Next - issues ready for development
- In Progress - issues in development
- Pull Requests - completed development awaiting client review
- Deployed - issues that are now working on production or demo site
In this process, project development starts with adding ideas and issues as separate items in the Backlog list. Well-defined issues are then coded and moved through the other lists in order until they are deployed. Sometimes we add another list, Merged, between Pull Requests and Deployed. The Merged list contains reviewed/approved work which is ready for prime-time but not yet deployed. This list is helpful when several individual issues need to be deployed at the same time.
The Trello process is lightweight and simple, easily customized for each project.
Lightweight, however, meant we were missing key metrics useful for reporting. Furthermore, there was no way to use current productivity to predict future timelines. Lastly, backlog management was hard for a large number of cards. In short, we were in need of:
- being able to answer "how long should this take?"
- having better categorization of work items and backlog management
- a strong sense of progression
- clients being in better control over prioritization of what we did next
- enforcing and tracking the status of backlog items in terms of readiness for development
Getting More out of our Process
For projects with longer backlogs, longer timelines, more complexity, and/or larger teams, we needed to wrap our Kanban-style process with better tooling, but also with the time-based iterations and story estimation that we find in Scrum.
As projects grow to require more coordination, process vigilance, vision and planning, Scrum allows us to enhance our process oversight. In addition, it generates output that can be used to help predict what will get done in upcoming weeks and months. This is extremely powerful.
On of the tools we use to manage this Scrum process is Jira though we have been considering ZenHub as well.
Our team employs the same tried and true value delivery process we have used for years in Trello. However, once we layer in Scrum onto the process, we are executing the workflow within time-based iterations, called Sprints.
An Introduction to Scrum
Upcoming blog posts will describe our Scrum practices in detail, so stay tuned! For the time being, however, here is a high level overview.
Stories
To define their goals, clients create Stories, adding them to the Backlog (a list of stories, bugs, and tasks). Each story comprises specific functionality. When added together, backlog stories create a picture of the entire project. Clients periodically prioritize backlog items because our development team addresses the most important issues first.
Grooming
At grooming meetings, clients meet with the Eldarion team to polish and evaluate backlog items. Polishing in this context means determining exactly what must be done to complete an item, and what criteria will be used to accept it's completion. Evaluation in this context means deciding if the item contains all information needed for development. Only items which pass evaluation are allowed to be pointed.
We often set these as a standing weekly meeting but we might pull these back to every other week or as needed as the backlog matures.
Pointing
At pointing meetings, the Eldarion team agrees on point estimates for a selection of groomed items. An interesting aspect to this process is everyone on the team must agree on a point estimate for an item, regardless of who will perform the work or who is the subject matter expert. Backlog items with point estimates can be used in Sprints.
Like the grooming meetings, we start out these being weekly and then reduce the frequency as we get ahead.
Sprints
With a nice batch of groomed and pointed development items, we can plan a Sprint with our client. A sprint is a finite period of time during which our team completes a specific set of development items. Sprint planning is the process of determining which development items are part of the sprint. Typically the planned sprint item point total is similar to the points completed in the previous sprint(s). This pointing system gives us delivery predictability, scaling nicely as the team expands.
When a sprint is concluded, we evaluate our completed sprint item point total and adjust the next sprint point maximum as needed.
Useful Definitions
- New product features are called Stories. Stories are typically written in the form
As a <ROLE>, I need <SOME FUNCTION> [because <SOME REASON>]. - Product defects are called Bugs. Good bug reports include steps for recreating the problem.
- The time needed to research an idea or prove a concept is called a Spike. When a client asks,
Can we integrate our data with XYZ service?we create a spike to determine the feasibility. - Tasks are items which don't fall into the other three categories. An example of a task is
Enable DNS for the Quality Assurance server. - A Backlog is a list of items (stories, bugs, tasks, spikes) which have not been developed.
Conclusion
By wrapping our Kanban-style process with Scrum, we are able to meet the demands of projects requiring larger teams, longer timelines, and/or more complexity. Doing this gives us:
- Predictability
- Categorization and Backlog Management
- A sense of progression
- Easier Prioritization
- Developer efficiency