During my time at Event Espresso, we’ve tried many project management tactics and just recently developed a method of project management that seems to be working for us, or rather me, since I am leading project management at the moment.
Here is my attempt to publicly share my thought processes and practices in regards to project management for our WordPress plugin, Event Espresso.
Delving Into Project Management
On a good day, from a project management perspective, the process of software development may look something like this:
However, we all know by now that that project management doesn’t always work like that, even on good days. As a project manager, we have lot’s of work to keep us busy for another decade and may even get to work remotely, from home, but we sometimes miss things or forget to ask the right questions. That’s why software development sometimes looks like the image below, rather than the nicely defined process above.
In essence, it was hard to determine where we should be spending MOST of our time. At the same time, I had this overwhelming feeling we’re spending most of our efforts on bug fixes and not working on features.
It didn’t feel like we were setting big-picture objectives at Event Espresso. Of course, I understood the importance of fixing bugs and making sure our software was stable, is of utmost importance. However, it seemed like we were forgetting about the backlog of feature requests, which was growing daily/monthly/yearly.
Too Many High Priority Tickets
In addition to not working on features and only focusing on bugs, it seemed we had a huge backlog of tickets all marked as “high” priority (most times arbitrarily by whoever created the ticket), but some hadn’t been updated in several months or sometimes in over a year.
I thought to myself if a ticket is a high priority but hasn’t been touched in over six months, while other lower priority tickets are continuously being worked on, then why have anything marked “high” priority? Especially if it’s not something, we are currently working on or plan to work on next or even six months from now?
Why not batch all the related tickets together into a project, then assign priority to the project as a whole? If the developers want to assign a priority for the tickets they are working on, then that’s fine, but most times the priority of those tickets was chosen arbitrarily by the person creating the ticket.
These were the questions and internal project management issues I needed to overcome if we were to succeed in producing and supporting a top-notch WordPress plugin on a shoestring budget.
Discovering a Project Management Process for Our WordPress Plugin
In this post, I’ll discuss the project management tools, strategies, and tactics that seem to work best for my team. I hope that these tips will provide useful insight into project management within committed teams of WordPress plugin developers and support staff.
Let’s proceed. Shall we?
Project Management Tools
First off, I just wanted to share a list of tools I use on a daily basis to manage a team of nine WordPress developers, support, and sales staff:
- Codebase – used as a private Git repository and internal issue tracker for all projects, including our core products, add-ons, and website properties.
- Github – used as public Git repository and public issue tracker for our core products and add-on offerings.
- Trello – online project management tool, used to track the progress of all current projects and related tickets, both internal and public. Trello also doubles as our “Public Roadmap,” which is perfect for allowing customers to vote on proposed features and track progress.
- Internal Blog – powered by the P2 theme for WordPress, this is where we discuss projects, track ideas, plan new features, prepare product launches, and share customer insights with everyone on the team.
- Slack – team chat on steroids.
Project Management Strategy
Our latest project master plan is adopted from an array of automobile and aerospace industry production strategies and techniques.
While managing a team of four full-time, distributed developers, and five support staff, over the last eight year’s we’ve experimented with many different methods of project management practices, recently we’ve developed a strategy for project management that works for us while keeping the project manager’s bus factor low.
Having a background in aerospace manufacturing, in-depth knowledge of lean manufacturing principles, and experience with quality assurance practices. I was able to combine many project management methodologies, such as lean and Kanban, into an easy to follow project management strategy that keeps developers focused on one project at a time. Meanwhile allowing them the autonomy and flexibility to take on high priority issues as they are introduced and also allows time for code reviews.
Using Trello to Keep Developers Focused
All ideas, projects, and issues we plan to work on are added to a card and assigned to a list in Trello.
The “Team Priority Lists” board in Trello is where we plan what to work on next, as well as track any projects that are currently in progress.
As you can see in the images above and below, each developers name is printed at the top of a list, then cards, which represent a project or issue ticket, are added to a developer’s list on the Trello board. Within each card in the list is a link to the Codebase ticket or Github issue. The Trello cards can also be used to discuss project timelines, ask questions, and labeled to show the current status.
Trello as a Visual Guide
Using the Trello board as a visual guide, developers only work on enhancement and feature tickets in Codebase or Github that represent one the cards in their respective column.
The great thing about this process is that a project card can be made up of one, or several tickets and might be a new add-on, core feature, or area of improvement. If the developer, support team, or PM needs to make a ticket related to the current project, the developer, PM, or maybe the ticket author should be involved in the decision to as to whether it should be worked on as part of the current project or added to the backlog or next phase.
If the PM is not available, the developer should make a decision and let the PM know of the decision or request further feedback. If a new ticket is created or an existing ticket is added to the current project, then that ticket should be added to the checklist in that project card.
In our opinion, there should be more batching work done (even on the same code branch) to fix bugs that are related. I guess it can be considered more of a project than a single bug process for development.
If the developer needs to make related tickets for a project or ticket they are working on, they can attach the corresponding tickets as list items in a card checklist. Here’s an example of a project card with a checklist:
As the developer completes the related tickets, they (or the project manager (whoever gets to it first) can only check off a list item when the corresponding issue ticket is marked as complete in Codebase. This way the developer and the project manager can see the progress of the project just by opening the card. The developer can also drag and drop the checklist items to organize the sub-tickets for each project, by dragging and dropping the list items into the desired order.
Top Level Priorities
Here is a short list of important projects to help communicate and establish a shared understanding of what is important to be worked on during any given month. Also, we can lay out what we think is/can be our priorities for future months.
Having a list of important priorities allows us flexibility when we want to spread the release of a new product over several months so that ALL of the envisioned functionality and details can be achieved in an exciting, timely fashion, i.e.:
- Month 1 : Introducing “AMAZING NEW THING”
- Month 2 : “AMAZING NEW THING : Now with LASERS!!!”
- Month 3 : “AMAZING NEW THING : It’s FINAL FORM!!!”
Prioritized Features or Enhancements
The next list can be considered a backlog of sorts. It’s a list of projects or tickets that are ready to be worked on. Each card in the list is assigned to a member, who is responsible for making sure the related issue or feature is progressed from planning to development, then testing.
As you can see at the top of the list I added an FAQ card that gives more details and includes a legend of card label colors. The image at the top of the column outlines the daily expectations of our developers, as they start their day.
Using Labels to Determine Status
As you may have noticed, we use labels on cards to show the status of individual cards. For example, developers can add a green label a Trello card, which means the card is “In Progress” or a developer is actively working on it.
Here are the labels we use:
- Red = Critical Priority: should be the current project (set by PM).
- Yellow = High Priority: only worked on when you’re blocked by further progress on Critical Priority cards (set by PM).
- Green = In Progress: what is being worked on right now (established by developer or PM).
- Blue = EEZ: tickets tagged as EEZ in Codebase.
- Black = On Hold: work was started but has been put on hold while focusing on other projects.
- Purple = Code Review: code is completed but waiting on code review from another developer.
- Aqua = Feedback Needed: needs feedback from a developer.
Projects Board
In addition to the “Team Priority Lists” Trello board, I keep another board just for maintaining a list of projects and tickets to work on next, without cluttering up the Team Priority List. I’ve also color-coded the board and separated each project into a list within Trello. Here’s how the Projects board looks:
In the same board, I’ve taken things a little further and created a list for each of the developers, like I did for the Team Priority List mentioned above, where I am able to plan out the next assignments:
Whenever a developers list starts to dwindle in the “Team Priority List”, I just move the cards from the project board into the respective list on the team list.
Project Management Tactics
We’ve tried many project management tactics over the year’s, including allowing ticket priority to guide the project and product releases. This strategy works okay if you have very few product offerings and are lean enough to fix issues as they surface. However, we’ve found that it works better to have a defined set of guidelines for the team to follow when reporting issues. Also, when allowing priority of tickets to guide development, you are basically telling your developers to work on whatever the hot (high or critical priority) is at the moment. Meaning developers are more likely to work on many projects but not complete them.
Below I will outline a few of the project management tactics that have worked well for us, so far.
Creating Issue Tickets
Issue tickets are created whenever a customer, developer, support staff, friend, or family member finds a bug in the software, no matter how big or small of an issue. It only takes a few minutes to report an issue for the developers. Once an issue is created, another support staff is asked to verify the issue. If the issue is determined to be valid, then the ticket is assigned to the project manager (me, at the time of this writing) for triage, along with a note about any additional findings.
I believe it is healthy for the support team to create tickets based on customer feature requests or issues, as it helps us keep an ongoing list of ideas for improvement. We may never get to each and every request, but that’s okay and should be seen as a good thing because that means we have an engaged team and customer base and endless supply of great ideas.
Everyone on the team (co-founders/owners, developers, project managers, and support staff) is able to communicate comfortably, and freely during the entire process of (and play an instrumental role in) defining project scope, validating product issues, and discussing solutions at every step.
Triaging Tickets
Most tickets, in my opinion, can be classified as a generic issue, unless it affects a critical part of the software functionality. Ie, the software is severely malfunctioning or customer data loss is occurring. However, if it is a critical or high priority ticket, then the person that created the ticket should inform the PM on duty and the developer it was assigned to so they can discuss where it fits into the Trello board. Next, a card should be created in the developer’s column (either by the PM or the developer) and labeled accordingly.
The person creating an issue ticket in the ticket tracker should assign the ticket to the current PM for triage. In our ticket tracking system, Codebase, we use a ticket status called, “Triage – Assign to PM”, which means that the ticket should be assigned to the current project manager, who will determine priority and assign to a developer.
The following screenshot shows an example of tickets (in Codebase) awaiting triage. Since I am currently the project manager, each of the tickets uses the “TRIAGE – ASSIGN TO SETH” status and are assigned to me.
By having all tickets assigned to me for triage, I can easily review and prioritize each ticket by creating a card in Trello, then copy and past the ticket URL into the Trello card, and add a team member to the card:
After I’ve created the card in Trello, I copy the short URL for the card and paste it into the Codebase ticket, then assign the ticket to a developer:
Brief Exploratory Phase
All reported bugs should undergo a brief exploratory phase when first worked on. So initially, if a bug appears to be high or critical, then it should get looked at immediately, but the developer should spend no more than one hour investigating the issue, and in that time either:
- fix the issue, because it was dead simple;
- or report back with findings and/or information regarding where to look further, etc
- in the second scenario, a bug should then be considered to require 4-8 hours to fix, and it can then be re-evaluated, as to whether it should be done NOW (because it is that important/bad) or fixed later because there is a better use for that 4-8 hours
Defining Ticket Priorities
When a ticket is created, the support staff is responsible for declaring the initial priority of the issue being reported (in Codebase or Github). Priority defines the order in which we should resolve a defect, which tries to answer questions such as, “Should we fix it now, or can it wait?”
The priority status of a ticket should be set by the support staff to the developer mentioning the time frame to fix the defect. If a high priority is assigned to the ticket, then the developer has to fix it at the earliest possible time. The priority status is usually set based on the severity of the issue being reported.
For example: If the ticket selector is broken on the single event page of a customers website, then the priority is “Critical” since it keeps the customer from selling tickets and making money.
Over time we have developed a system, which was discussed thoroughly in our internal blog, where we defined ticket priorities which can be assigned to tickets according to the guidelines outlined on our internal blog.
Here are the ticket priority guidelines we have outlined on our internal blog:
Critical – a ticket that meets at least one of the criteria below:
- Is unexpectedly altering data records
- Is unexpectedly prohibiting or allowing registrations/transactions
- Is unexpectedly prohibiting or allowing: access, entry, and retrieval of data
- Is entirely prohibiting expected workflows, no workaround is available
- Is unexpectedly prohibiting activation/deactivation
- Is perceived to affect virtually all users
To be worked on immediately
To be released immediately
High – a ticket that meets at least one of the criteria below:
- Is unexpectedly hindering normal workflows but a temporary workaround is available
- Is perceived to impact a large segment of the user base
- Is unexpectedly interrupting desired workflows that cannot be worked around with user code (including actions/filters) without modifying core files
- Is expected to significantly improve normal workflows
- Is a new workflow (feature) with no workaround
To be worked on after Critical tickets.
To be released at a normal interval with other tickets.
Normal – a ticket that meets at least one of the criteria below:
- Is perceived to be a small improvement to normal workflows
- Is perceived to impact some of the userbase
- Is unexpectedly interrupting desired workflows that can be worked around with user code (including actions/filters) without modifying core files
To be worked on after High tickets.
To be released at a normal interval with other tickets.
Low – a ticket that meets at least one of the criteria below:
- Is unknown whether it will improve normal workflows
- Impacts a small portion of the user base.
To be worked on after Normal tickets.
To be released at a normal interval with other tickets.
Discussing Strategic Priorities with the Team
Given that resources are limited, we want to make sure we are focusing our time, talents, and energy on what we think is most important. With more planning and goals, we believe we can improve our processes to more reliably work on and finish what is most important. These important things could be fixes, enhancements, new features, new products, new services, investments, etc.
One of the ways we use our Internal Blog (powered by the P2 theme) as a communication tool is to encourage everyone on the team to list the top three priorities they feel should be worked. Periodically, we will post a topic asking the team what should be worked on within the next six months and three more priorities for what we should work on in 6+ months.
We encourage the team to think about it in the following ways for both the short-term (6 months) and the longer-term (6+ months) to stimulate their thoughts:
- What should we do to keep our jobs (not that our jobs are in danger)?
- What major bugs/systems need to be refactored?
- What add-ons do we need?
- What features do we need?
- What service do we need?
- What keeps coming up?
- How do we grow in the right way?
- What should come first?
- What should we do sooner (because there is more value in doing it sooner)?
- What should we do later (after we know more or the value doesn’t change no matter when we do it)?
We don’t expect answers to the above questions in their response, these are just to help them think about what the top priorities should be.
We also understand that some feature requests are a fad, or the vocal minority seem to pressure action. So we try to be careful not be misled by a single point of data.
If someone on the team feels that a significant priority is under-represented, we encourage them to enlighten the rest of the team about why it could be so important.
I think I read somewhere that 37 Signals doesn’t keep a list of feature requests. Instead, they choose projects based on what requests persist over time. We encourage the team to always keep on the top of their minds what we need to do next.
Strategic priorities do not exist in a vacuum. Priorities can change based on market conditions, resources, etc., so we keep this process going periodically.
Insight Into My Project Management Thought Process
A while back, I started reading this book called, “The Goal: A Process of Ongoing Improvement.”
The book is about a manufacturing plant manager that’s trying to improve the performance of his production plant to keep it from shutting down. The plant manager and his team were forced to come up with a plan to increase revenue and ship more products. What he and his team found when starting out on this venture is that their plant was not running at capacity and had developed many bottlenecks and processes that were keeping finished products from shipping on time, if at all.
So they had to look at all of the processes throughout the production facility to identify bottlenecks, high/low volume workstations, and old processes that no longer worked. They had to come up with a solution for moving work through the plant in a manner that used high-output workstations to their full potential while making sure the bottlenecks could keep up with the workload.
After investigating, they found that many small batches of jobs or a single part kept getting pushed to the front of the line because they were prioritized higher than other larger, high-volume jobs that were worth more revenue when completed. Most times the small jobs or single parts were pushed through at top priority because a client needed it right away or a single part out of a batch didn’t pass Q/A, and they didn’t have any reserves. They found that the workstation managers were getting interrupted by the high priority jobs for various reasons, which meant deadlines on the bigger jobs were pushed back because the workstation had to be stopped, then a new part loaded, which could take 30 minutes, to an hour to get set up for a new part.
A lot of what I read reminded me of when I worked in a jet engine production facility while in high school. The production facility was set up a lot like what I read in this book, with color code stations, color-coded priorities, and color-coded lines on the floor to guide the order of process.
Just for fun, I dug up this old newspaper article about the high school aerospace program I was enrolled in. This newspaper clipping dates back to May 30, 1995 and features me at a manual lathe with a facility worker (no, my name was not Juan Dominguez at the time, they messed up our names.):
In the manufacturing plant I worked at, the parts we created started off as raw, metal objects, say a cylinder or disc that needed to be treated with heat, then cut with a lathe, then back to heat treat, then to a CNC lathe or mill, then off to Q/A (quality assurance). The original order number ordered most jobs from when the purchase order was received. Each operator at a station usually had a few jobs in their station at any one time but could only work on and monitor one job a time. The workstation operator usually just picked the job with the lowest order number because that was older than the other orders with higher order numbers. They would also try to group orders with similar parts together so that more than one order is processed at once, even if it was something with a higher order number. That way they didn’t have to break down the machine, select new tools, run the setup, then run parts through the machine, test measurements, etc. However, sometimes jobs came in with a red or yellow tag that meant the job needed to be completed within the next 24 hours (red tag) or 48 hours (yellow tag).
If a high priority order or a reworked part happened to come through while the workstation was processing a large volume order, the high priority order took up a spot after the current order(s) being processed. That way the workstation didn’t lose precious time breaking down and setting up for the “hot” item as they called it.
I felt that we could run our processes similar to a production facility in some ways. The Team Priorities Trello board can be thought of as the production floor, with each workstation and its abilities outlined using lists in Trello. Each list (workstation) uses the name of a developer, then below that, using all caps title cards, are the things a developer is responsible for looking at when first coming online. The cards with regular cap titles below all caps cards are the jobs or projects in the developer’s current queue.
If there are no cards in the developer’s queue, then they can go to the “Prioritized Features or Enhancements” list to pick up the next project in the line for which they have been assigned.
Wrapping Up
I know I’ve written a lot here and plan to expand on these ideas and challenges in future posts. If you have any feedback, questions, or just need clarification, please let me know. Also, if you have any questions or want feedback on handling certain scenarios, don’t be afraid to ask in the comments below.
