The methodology for tackling a complex project shouldn’t itself be complicated.
I’m EVP of Delivery for Basalt, and during my five-plus years of experience managing agile teams for enterprise companies such as Twitter, Workday, and Johnson & Johnson, I’ve learned that the best systems are the ones that get out of the way and allow teams to focus on the product.
A sound, simple methodology is key to successfully planning and implementing Component Driven Development projects. Here at Basalt we use Pattern Lab as our main tool to develop design systems The hard and fast rule throughout: keep things simple when managing tickets in JIRA. But before the project enters the JIRA phase, the team figures out exactly what the project consists of.
Transform product needs into components
Because components are the basis of the project, the team’s first task is to determine what those components are. During requirements gathering, we review the site layout, site structure, site functionality, and determine which items span across the site that can be reused; essentially turning them into components.
Once we’ve identified our components, we start a "parent" ticket called a Component Overview Ticket.
Examples of Component Overview Tickets are:
- Media Block: Text block + left/right/center aligning media (image, video, etc)
- Basic Block: Title, text field, and optional CTA
- Hero Block: Hero image, text overlay, CTA
Essentially, identifying and creating Component Overview Tickets is the first step in dividing a larger project into a series of discrete, specialized tasks. But in order to make each task actionable for the entire team, the next step is to roadmap each Component Overview Ticket, from inception to implementation.
Specify your Component Overview Tickets
Once Component Overview Tickets are identified and created, we break each Component Overview Ticket down into three simple tasks. No matter the type of component, the three tasks are the same:
Media Block: Text block + left/right/center aligning media (image, video, etc)
Basic Block: Title, text field, and optional CTA
Hero Block: Hero image, text overlay, CTA
Build, Style, Implement
Each Component Overview Ticket is broken down into three stages, and each stage becomes its own sub-ticket: Build Tickets, Style Tickets, and Implement Tickets. The function of Build, Style, and Implement Tickets is to clearly define the task while keeping the granular product—the eventual component—indelibly connected to the overall whole: the site at large, and every page of which the component will be part. (More on pages later.)
Important to remember: each sub-ticket (Build, Style, Implement) remains connected to its parent, the Component Overview Ticket. To save time, and reduce redundancy, a parent ticket may contain information relevant to a sub-ticket which only appears on the parent ticket (example: Build, Style, and Implement Tickets typically contain very little description or attached comps as these are in parent Component Overview Ticket).
Here’s an overview of the key traits of each genre of ticket:
- All about the backend--Build Tickets create the functionality in the CMS to be able to create, read, update, and delete that content
- Is viewable in the CMS backend (i.e. editable in Drupal/Wordpress/Etc.)
- Contains story points for how much work the backend needs to do to Build
- All about the frontend--guides the process of adapting component wireframes/mockups and create the component in the browser by writing HTML, CSS, JS
- Is viewable in the Design System/Pattern Lab
- Tests how a component acts at different screen sizes/devices
- Contains story points for how much work the frontend needs to do to Style
Implement Tickets (dependent on Build and Style Tickets)
- All about gluing the backend and frontend (Build + Style Tickets) together
- Is blocked by both Style and Build ticket
- Creates the finalized component in all it's glory: you can see it & you can edit it
- Contains story points for how much work it takes to map the data between backend and frontend
- Can be done by backend or frontend developer
Get ready to build smart
Once components are identified, Component Overview Tickets are created, and Build, Style, and Implement Tickets are fleshed out, the project has begun to take conceptual form. But before jumping in and tackling the project task by task, we sequence the project with estimation and right-sizing. Because components are the bedrock of the product, we alway size at the component level. And because building, styling and implementing in a communicative, iterative fashion that requires everyone’s active input, our story pointing always involves the entire team.
Know your component tasks requirements intimately
Each team member—developers, designers, testers, analysts, QA—brings their own valuable perspective to the project and to the work required to deliver a component. First, the whole team weighs in (and plays planning poker) to identify the component the team agrees is the least complex. With the smallest component task identified, the team sizes it according to a Fibonacci-like format with a point value--0.5, 1, 2, 3, 5, 8, 13, and so on. With this task identified, and given the most granular point value, the right-sizing of each consecutive component is relevant to each team member, because its value is determined by the project itself.
This Ticket-based methodology helps keep projects on task, on time, and under budget--it helps the project go smoothly.
Additionally, I believe strong tracking and documentation is KEY for a successful project. Having everything organized and documented fosters better communication through all parties: client stakeholders, the project team, internal teams, vendors, etc. With strong tracking, one is able to watch the team's velocity per sprint and evaluate where and how to improve the team's velocity with each sprint. But our methodology is also invaluable when things don’t go as planned: C Y A! (Cover Your Ass!) Proper documentation and communication go a long way, especially when projects go awry. Our ticket-based methodology tracks and documents in detail for every step of the site build.
For all the talk of a “component-based, not a page-based” approach, at the end of the day, the client is expecting pages—and that's what we'll need to deliver. Thus, though our team works on the component level, page tickets are beneficial for helping clients conceptualize how the project will look page-by-page.
Here's how we handle Page Tickets:
- Make a page ticket for each page (or type of page really)
- These can contain the full page comps
- These have no story points
- These JIRA tickets are linked to all the Component Overview JIRA tickets and show which components are needed to build the page: this let's us know the work that needs to get done to build that page.
Most story points exists on the Build, Style, or Implement tickets and not on the Component Overview ticket nor on the Page ticket. This gets around the primary problem with using a page-based approach: if we story pointed the effort to build each page (and pages contain components that are used on multiple pages), then we'd end up accounting for the level of effort required to build components multiple times--and our estimates would be off.
Here's how the tickets would link in this highly technical and detailed outline: