17 minute reading time; ~3200 words
Greetings!
So far in this series, we’ve taken our project from a single idea all the way to a design of the system needed to support it. Here, we’ll take that system design and plan out the work needed to breathe life into it.
Development planning is all about breaking the system design into workable pieces. This includes estimating how long they might take to build and in what order, and creating a roadmap to complete our project.
In this post, we’re going to talk about how to break down technical tasks into specific deliverables, generate estimates, prioritize and order the work, and finally some common challenges in delivering a project.
Strap in for this one, because there’s a lot to talk about!
If you haven’t read the previous posts, I’d suggest you start at An App From Scratch: Part 1 – What To Build. You can also find all the related documents and code here: Building Tailgunner.
From Story To Tasks
Now that we have the information we need about our story, the process is fairly straightforward. As the developer, I’m going to take the MVP feature (“Create a tool to allow users to create templates”), and use that as the foundation to establish the system and functionality. By the end of the first phase of this project, we should have:
- a running production server.
- a basic page to list the templates belonging to the business owner.
- a way for the business owner to create a template.
- some basic testing.
- a production deployment pipeline.
With these goals in mind for the project’s first phase, let’s get started creating our list of tasks.
Initial Technical Task Breakdown
To create a list of deliverable tasks, I first start with a high-level overview of what we want to do. The goal for the developer at this stage is to come up with a list of concise sentences that cover all required work. We’ll expand them later, but the intent of this is to be able to frame each piece of work just enough to be able to talk about it.
- Create database tables.
- Create page to list templates.
- Create form to create new template.
- Set up production server and deployment process.
After discussing this list with a senior or staff engineer, an engineering manager, or other technical stakeholders, and comparing these tasks to the supporting documentation, we should be confident we have a good initial breakdown of the work.
This is the point where you can create a high-level estimation of the work if needed, to help inform the product team of if this work may or may not be viable for their timeline.
Once everyone is in agreement on this initial plan, and have had time to check that the work makes sense for the desired timeline, the next step is to detail out the technical work and expectations for each task.
Detailing The Tasks
By the end of this process, the developers should have a clear understanding of each task, the work involved, and the requirements to complete it. We’re going to use Agile cards to describe the work.
What Are Agile Cards?
Agile is a development methodology designed to help plan and deliver projects. It focuses on small, deliverable pieces of work, allowing us to incrementally progress to our goal while having the flexibility to adjust as needed.
Each card should outline a specific piece of work that needs to be completed, and the criteria for its completion.
Here you can find an example card:
Title
A short descriptive title for the task. The title should be clear enough for all stakeholders to get a quick idea of the work the card will address.
Type
There are a few different types of cards that people usually use, depending on the business. These are the most common:
- Story
A “why and what” card, these are closer to the stories a product team will produce, and capture work that delivers specific user value. In Scrum, these are assigned points. - Task
A “how” type of card, these usually address more technical implementation details. While the work doesn’t usually deliver direct user value, they are still essential. In Scrum, these are assigned points. - Bug
These cards address bugs that were discovered during testing, or resulted from previous work. In Scrum, these cards aren’t usually assigned points if they came from recently completed stories or tasks. - Spike
This type of card is used when we know how long we want to spend on a task, but not how much work it is. They’re usually used for research tasks, or other open-ended work. In Scrum, these cards are not assigned points, as their nature is work bounded by time, not goals.
Description
This is a short description of the work to be done. The intent of this section is to give a quick view of what’s needed, without getting too in the weeds. Any details should be outlined in a Details section, below the Acceptance Criteria.
For a story card, the first sentence should follow the format: “As a <user type>, I want <the specific feature or functionality>, so that <a goal this story should satisfy for the user>”.
For the other types, this is more freeform, and should aim to capture the work however it makes sense to explain it.
Acceptance Criteria
This section is a bullet point list of criteria that must be met to consider this card completed. The criteria should be specific enough to satisfy all stakeholders, without being overly prescriptive of the implementation, unless it’s a strict requirement. Avoid repeating specific details documented in other places.
Good criteria:
- The database tables from the defined data model exist.
- The models required to access these tables exist and are working.
Potentially bad criteria:
- The database tables must be written in SQL, and all fields must have detailed comments.
- All fields must be defined by foreign keys if they relate to other tables.
Details
This section is optional, but if added, should include any specific details to assist with implementation. It may include links to other documentation, or detailed descriptions of technical elements.
If you want to dive deeper, you can start here: Work items: spike, user story, task, and 🐞
Now, let’s start making some cards!
Card: US1-C1
Title
Create database tables
Type
Task
Description
Create the database tables required to support creating a template and store their fields.
Acceptance Criteria
- The database tables from the defined data model exist.
- The models required to access these tables exist and are working.
Details
See the tables documented in the technical plan.
Card: US1-C2
Title
Create template list page
Type
Story
Description
As a business owner, I want a page that will list all templates I own, so that I can manage and work with them.
Acceptance Criteria
- A tool exists to list all templates the business owner is allowed to see.
Details
- Create the API endpoint
GET /api/v1/template - Create a page to list the templates: Mockup
Card: US1-C3
Title
Create tool to add new template
Type
Story
Description
As a business owner, I want a way to add a new template, so that I can create a new data set.
Acceptance Criteria
- There is a way from the template list page to open the template add tool.
- The business owner is able to create new templates that they own.
- New templates show up in the template list.
Details
See the system diagram for creating a new template.
Card: US1-C4
Title
Set up production server and deployment
Type
Task
Description
Create a production webserver, and implement a deployment workflow to get our code into production.
Acceptance Criteria
- A server exists for
tailgunner.app, running the latest main branch code. - New merges to main are deployed to the production server.
Talking about acceptance criteria again, I want to highlight two examples from the cards above.
There is a way from the template list page to open the template add tool.
This criteria was originally worded “There is a button on the template list page to add a new template”, but in reviewing it, the wording was overly specific, as it dictated the UI within the criteria. This removed some flexibility, and if the designer or developer later wanted to change that button to a link, this card would also have had to be updated.
New merges to main are deployed to the production server.
Notice that I didn’t specify whether there should be an automated or manual process for deployment. This allows us some flexibility in the process we pick, because automation isn’t the focus of this card. While I’ll likely create a manual deployment, this acceptance criteria allows me to choose based on my timeline and workload.
Estimation
Now that I have some cards developed, it’s time for estimation. Whether this is a required part of the process depends on the project, team, and general scheduling. The amount of detail for this estimation is also variable. This process is a whole topic of its own, but I’ll give you a brief overview.
In a project involving other teams, where you’re deploying an end user feature, or there are multiple business stakeholders, you might have to estimate every card to a high degree of confidence and provide a specific delivery date for the project plan. In other cases, you may only need to t-shirt size the effort, so that you have a rough idea of the effort and can ballpark a number of weeks or months to delivery.
Estimation Methods
There are a few main methods of estimation, providing different levels of confidence. Regardless of how you estimate, always leave yourself a buffer. The amount of buffer is a bit of an art and will vary between teams, but the overall goal remains the same: reduce the uncertainty to a manageable level.
The two techniques generally used are:
- T-Shirt Sizing – Small, Medium, Large, XL
This technique is a quick way to compare tasks and get a general feel of the effort involved. This can get you to an estimate of weeks to months. - Fibonacci Sequence – 1, 3, 5, 8, 13, etc.
Anything above a 5 indicates a high level of uncertainty generally, and tells you that you should break it down into smaller tasks if you can. This method can get you to a highly accurate estimate when used correctly.
Team Involvement
I’ve had the best success in producing accurate estimates by making sure the entire team is involved in estimating any cards that needed a high level of confidence, using the Planning Poker method.
Involving the whole team, even if they’re not going to be working on that specific project, makes sure each card is well understood. When people don’t pick the same scoring for a card, we very quickly discover assumptions and misunderstandings about the scope of work. Reaching consensus among a whole team means we have a solid understanding of the work, and again reduces our uncertainty.
Ultimately, this process is about reducing uncertainty. We can’t get perfect estimates, but we can strive to understand the work well enough to deliver reliable ones.
Making Our Estimates
Using the cards above, I’ve done some t-shirt sizing. Given that I’m working solo with no deadline, this is the level of complexity I need for this project.
| Card | Estimate |
|---|---|
| US1-C1: Create database tables | Small |
| US1-C2: Create template list page | Large |
| US1-C3: Create tool to add new template | Large |
| US1-C4: Set up production server and deployment | Medium |
Prioritization
Since this is a low complexity phase of the project, the prioritization is fairly straightforward. However, it’s not always the case. There are multiple ways to prioritize, and which you use depends on the project needs. I’ll give you some examples of how I’ve prioritized work:
Project A – Tackle the most complex work first
This project was a technical upgrade for all the database servers in an organization. There was a defined hard deadline, after which we would start incurring higher costs until we completed the project. After detailing the work, we chose to tackle the most complex work first, starting with the most used database table.
This ensured that we’d get the hardest part done early, de-risking the rest of the timeline, and providing us with valuable learnings to apply to the rest of the upgrades.
Project B – Unblock other teams
In this project, we were working on a complex user-facing feature to schedule a new automation related to their projects. The key factor here was to ensure a stable feature, in collaboration with multiple frontend teams. Once we had completed estimation, we prioritized the functionality that would unblock the frontend teams the fastest, allowing them to move from mock API endpoints to functional production endpoints early in their project.
This choice enabled them to release components of the new functionality (behind feature flags) earlier in their development workflow, which partially unblocked QA, allowing us to then get early feedback on the new APIs.
Project C – Build confidence
The project involved building a new greenfield system to track and audit internal financials sourced from multiple systems. This was a long project, so we chose to prioritize the smallest data feed, because it allowed us to build confidence in the design rapidly, while not having a large impact if we had made the wrong decision.
As you can see from the examples, there are many ways to prioritize the work, and they don’t have to be mutually exclusive either. You can always re-prioritize work through the project, and depending on your methodology, you may even do this every few weeks. The key point is to have a clear and stable view of your goals for at least a week or two at a time.
Tools
I’m only briefly going to touch on this, because there are dozens of tools to manage a project. By this point, you’ll want to have:
- A Kanban board to track and visualize tasks.
Suggestions: Trello, Jira, Github Projects, Obsidian Kanban plugin, or even a spreadsheet. - A documentation system to track the details and supporting documentation such as designs, workflows, interfaces, and other artifacts.
Suggestions: Confluence, Obsidian, Google Drive folder - Time tracking (optional): If used, it can provide a rough benchmark of task durations, and might partially help your estimation process.
Potential Challenges
Scope Creep
Scope creep is one of the the most impactful challenges a project can face.
What Is Scope Creep?
Scope creep occurs when new additions to a projects goals, deliverables, or requirements appear, but without matching adjustments to the projects timeline, budget, or resources. It often sneaks up on a project through ad-hoc requests, poorly defined scope, miscommunications, or shifting business priorities.
Examples
- “Can you add a button to delete the template right from the new template created dialog?”
- “I found this bug in X while I was testing Y. Can you fix it please?”
- “It would be nice if the create dialog displayed sparkles when you clicked Create.”
- “We need the Create workflow to send the user directly to the edit page for the template, didn’t I mention that when we talked about it a month ago?”
- “The stakeholder decided the user should be required to add a template field as part of the create workflow. Can you update the dialog to show that?”
- “I need a report on how many business owners we have, the last time they visited, and three other fields.”
Every project is a negotiation, including for adjustments to the work. However, unchecked scope creep is to be pushed back on at every opportunity. The key to a successful delivery is that these requests become formal adjustments to the project, with corresponding changes to the delivery scope or timeline.
My guidance for managing workload and scope creep has always been: “if a request takes more than 20 minutes, send them to talk with me, or put it in a formal request. If you get more than one or two a week, send them to talk with me.”
The biggest impact of scope creep is that the project gets delayed, or misses a critical deadline. However, there are other potential impacts as well, including:
- Reduced quality of deliverables, as time is diverted from other areas.
- Diminished morale, or increased stress, because additional work without additional time will make them feel pressured to deliver.
Estimation Errors
It’s not so bad if a task was over-estimated, but it can really disrupt the team’s week if something critical was under-estimated. As you’re working through the project, if you discover that you’re not on track to meet your estimate on a piece of work, or the overall project, it’s best to communicate early that this might be an issue.
By addressing the problem as soon as you recognize it, stakeholders have the chance to evaluate the impacts, and make a decision about how to handle it (usually by adjusting the timeline or cutting some scope).
Resource Bottlenecks
These bottlenecks can occur and be recognized at any point in a project. Perhaps a specific person must approve certain pull requests. There could be a team that has too many projects in their list, and won’t be able to deliver their piece of your project until a specific time. Maybe you need ongoing support from an external vendor.
Identifying these bottlenecks, and planning how to resolve them or mitigate their impact is essential, and should happen as soon as you recognize the issue.
Other Challenges
The three challenges above are just some of the most common problems. Some other issues include unclear responsibilities, misaligned expectations, process errors, and testing problems. Through all these challenges, there is one critical factor will help a project get to the finish line: communication.
When you discover a problem, you should always talk to your team, your leaders, or the stakeholders. No problem should be a quiet problem, because you need to give others the opportunity to be aware there is a problem, so they can help address it.
Wrapping It Up
Now that we’ve taken an in-depth look at development planning, I want to highlight the most important thing that this whole series is trying to teach you:
Communication is the most critical factor to project success.
This series has focused so far on showing you a structure to help you build a shared understanding of what the project is, and how you want to approach it. However, the core lesson has been about the importance of communication.
Talk through your goals, designs, and what the work actually aims to accomplish. Politely disagree, debate, sketch ideas, advocate for your vision, find common points of agreement, but above all: talk about the work, how it’s going, and what it means.
The tools and processes I’ve shown you are just one way to do that. While they might not be the best fit for your project, the key elements are staying focused on your goal and how to get there, planning effectively, and keeping open communication with everyone else involved. With these, you can get anything done!
As always, I’d love for you to share your thoughts in the comments below!
Thanks for taking the time to read this, and stay tuned for the next part: building the card US1-C1 Create database tables.
Cheers!
Leave a Reply