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.
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).
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.