Software, Development, and WordPress

Project Management: Features (Milestones, Tasks, and Feedback Loops)

Project management is multifaceted, and the way we all go about breaking up the various aspects of our projects are likely contingent on how our place of employment does it, how the client wants to do it, or how we opt to do it ourselves.

For this post, when it comes to working specifically on any given project, I’m specifically talking about how we take the requirements of a project and break them up into more manageable pieces and deliverables for the people for whom we’re working. And in doing this, I think it’s important that they’re kept in the loop and can see progress at the proper checkpoints to garner feedback.

Despite changing various aspects of my business as I’ve learned more about what works and what doesn’t, one thing that’s remained consistent in how I handle the development-related aspects of features of a project.

Features: Milestones, Tasks, and Feedback Loops

Whenever we get into talking about this kind of stuff, it’s easy to slip into the jargon of our industry. And though I don’t think there’s necessarily anything overly technical about “milestones” and “tasks,” a “feedback loop” is something that’s a bit different. But I’ll cover that momentarily.

Given a set of requirements, no matter how large, I immediately start going through the document – regardless of how we receive it – and thinking about all of the pieces that will be required to achieve a given feature. Regardless of the languages, tools, frameworks, or applications with which you choose to work, I believe this is where having a deep familiarity with what you work with significantly matters.

Project Management: Features

Breaking features into milestones and milestones into tasks.

From there, I’ll then take a given feature a break it down into various tasks, and I’ll repeat that for each of the features. Usually, I’ll try to make each feature a milestone, but some features are bigger than others and have to be broken up into multiple parts. To that end, a project is usually split such that:

  • A feature becomes a milestone (or milestones),
  • A milestone is a group of tasks,
  • And a task corresponds to a functional unit (not necessarily a function in the overall codebase, though).

Then, you can work backward from this to see how it corresponds to a release:

  • A task usually corresponds to a commit,
  • A set of commits corresponds to a tag,
  • A tag corresponds the merging of a feature,
  • A feature corresponds to a milestone.

At this point, a milestone should be ready to deploy to the staging environment so the customer can evaluate it against what s/he has in their mind (and in the requirements) to make sure it’s met.

This is where a feedback loop comes into play. But first, I define a feedback loop simply as:

A conversation around a given feature that determines whether it’s finished or warrants more work.

Though others go into much more detail. I digress, though.

So while waiting for the customer to get back in touch regarding the latest milestone, then I – or we – will typically move forward with the next milestone. This is why it’s important to have a consistent way of working with milestones, tasks, and feedback (along with branches in source control and staging environments).

Project Management: A Process

Start working on a new feature after committing the last one to source control and staging.

If feedback comes back from the customer, then we’ll typically take the feedback, determine what can be done, what can’t be done, and then we batch it into a new milestone. Sometimes, the milestone is added to the end; other times, it’s added as the next item of priority. It all depends on the nature of the work, the feedback, and how it fits into the scope of the project.

More Than Features

Generally speaking, this is just a high-level view of how I try to manage the development aspects of features. But looking at milestones, tasks, and feedback loops are something that’s important because once that system is in place, it creates a predictable way that you and a team can implement solutions.

Further, it creates predictability with deliverables and communication with your customer, and this works especially well with repeat customers, too since they know what to expect.

As with many of the things with which I write about, I don’t try to present this as gospel, but I do believe that having some system in place is important. I don’t think one should ever wing a project unless it’s just a personal, side project.

So regardless of the approach that you choose, at least have an approach.


  1. Bobby

    This is great. I’ve had this open in my mobile browser for a few days and finally got some morning reading time.

    I just grabbed a sheet of paper and basically redrew your diagram.

    I’ve been thinking about processes a lot since I started jiu jitsu a few months ago. It’s all about metacognition and figuring out the best path for yourself, so I’m glad you added that part at the end too. That lesson from jiu jitsu has definitely carried over to the rest of my life.

    Anyway thanks for sharing and getting me thinking about how to do this better/right for me/us.


    • Tom

      This is great. I’ve had this open in my mobile browser for a few days and finally got some morning reading time.

      Wow, thanks — I appreciate that!

      That lesson from jiu jitsu has definitely carried over to the rest of my life.

      Though I don’t practice martial arts, there are other fitness activities in which I’m involved and though they often work opposite sides of the brain, they feed into each other and it’s really neat to see how things work back and forth with each other as long as one is actively paying attention to what they are doing.

      I’m glad this is helpful!

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑