Spinning Up A New Project
Tags: projectmanagement, stories, writing, project
Published: 2020-03-17 16:15:18

---
title: Spinning Up A New Project
published: true
description: A description of my process for building up the queue of work at the start of a new project.
tags: Project Management, Stories, Writing, Project
---

##Sections
* [Disclaimer](#disclaimer)
* [Intro](#intro)
* [Where to start? Epics](#epics)
* [Adding cards](#cards)
* [Prioritization](#prioritization)
* [TL;DR](#tldr)

###Disclaimer, disclaimer, disclaimer<a name='disclaimer'></a>
This is a description of the process I have found success with when tasked with building up the queue of work to get a project kicked off. There is no singular best way to do this. This is just my way. If you have a different way that you've found success please leave a comment. I am always trying to iterate on my process and make it better.

###Intro<a name='intro'></a>
I am a developer by trade, but when working at small companies you get the chance to wear multiple hats. Both my current and previous employers have either used [Basecamp's Shape Up](https://basecamp.com/shapeup) or something in that spirit. In both cases we choose projects that are scoped to fit in a cycle size, divide the full development team in to project teams where one developer is the lead for this project, and let the project teams figure out how to get the project done. The reason we have a project lead is because we've found it helpful to have one person on the project focused on organizing the work and managing lines of communication while the other members on the team focus on writing code. It is this project lead role where I figured out my process for spinning up a project.

###Where to start? Epics<a name='epics'></a>
Epics, milestones, or whatever term you want to use are always my starting point. I use epics to break down the project in to chunks. Each epic should deliver some value. If possible the first epic should be an MVP, something small that doesn't do much, but does do something of value. Each additional epic should build on that MVP to continually add more value. This way if you run in to a blocker that prevents you from finishing the project's entire scope you've still delivered something.

1.Create the epics.
  * Think about your project and add epics for your project. The epics you add will be specific for your project. Once you've made your first pass take another to see if you want to combine or break up any milestones.
  * If one milestone depends on another mark that dependency now.
  * _NB: I also always add a 'Nice to Have' epic that is a catch all for all the stories you come up with that don't fit in another epic or are outside the MVP scope of the project._
2. Size you epics to your timeframe.
  * Take a guess at how long you think each milestone is going to take. This first pass doesn't have to be accurate just get something down.
3. Add the details.
  * Add a brief description of the goal of each epic. I usually start with a high level statement like, "When this epic is complete _this thing will be possible_."
  * Add any bounds you can think of. This will help you when you add stories, but it will also be informative for your teammates picking up cards.

###Adding cards<a name='cards'></a>
1. Start with the first epic and add some cards you think you will need. 
  * Just add titles for now.
  * I like to use action statements.
2. Repeat step 1 for the other epics.
3. Go back through each cards and add some details.
  * Start with a high level statement like, "When this card is complete _this will be done_."
  * Add links to documents, scope bounds, code snippets, possible approaches. Whatever you think may be helpful to the person that will pick up the card.
4. Continue to add details in an iterative approach.
  * You don't need to fill out all the details for a card on the first pass. Adding details to one card will often make you realize that you need to add something to another card.
  * Add any details that you would want if you were going to be working on the card.
  * Try to keep the format between cards the same so that people know where to find the information.
  * _NB: Don't sweat this part too much. You are going to be adding details throughout the project as you learn more._
  * _NB: You should encourage your teammates to ask questions if a card isn't clear to them. That way you'll both be on the same page and you'll get better at knowing what to put in future cards._
5. Repeat steps 1-4 through out the project adding cards and details as you learn more.
_NB: If you write a card and then decide it doesn't fit in the MVP scope move it to the 'Nice to have' epic then you can evaluate its value later._

###Prioritization<a name='prioritization'></a>
Once you have created the epics and cards you should need to organize them in to the order that they will be worked on. You probably already did a lot of this while writing the cards, but now is a chance to look at everything at once and see what you might want to change.
1. Start with the epics. Make sure they are in an order that makes sense.
2. Look at the cards in each epic and make sure they are in an order that will limit the number of blocking cards to the best of your ability. You can't always avoid cards blocking other cards.
  * If a card is blocked make sure you call it out in the description. That way someone doesn't pick up the card and start on work that ends up being blocked or wasted.
3. If you are using a backlog organizing you can organize cards across epics in to the backlog. This is always complicated. If your team is small it probably makes more sense to focus on one epic at a time and pair when there aren't enough cards available for everyone. Everyone should be pairing more anyway.

###TL;DR<a name='tldr'></a>
Start at a high level and iterate getting more and more detailed every pass. If you and you teammates communicate when something isn't clear the epics and cards don't have to be perfect, only good enough. Just like with code I find my best epics & cards come after many iterations and revisions.