3 Checkpoints for Your Development Process

earlier this year i published the 3 checkpoints for your agile project management tool blog post.  as a reminder, the 3 checkpoints are these:

i’m making this reference to give a clearer idea of what my today’s post is about. the very first bullet — process first, tool next — deserves a closer look. what happens in the phase which goes between “process first” and “tool next’?  a diagnostics check of the development process. we need to be aware of any peculiarities of the real development process to select a tool that would be capable to replicate it.  so, what are the things to note about the process that one would definitely need in the tool?

first, you need to break down your development process into these 3 parts:

this high-level representation will work as a good reference framework to cover all the essential details of the process that needs to be replicated in the project management tool. i’ve compiled a list of questions that would help stakeholders check if a tool is capable to mirror the process. let’s go over each of those 3 major checkpoints.

work

1. which work items are you using? how is work broken down in your development process? how many levels of hierarchy do you need for your work items? just for the sake of example, the hierarchy can look as follows:

idea (issue) -> epic -> product->project->feature-> user story->task

a special attention should be paid to the levels of hierarchy, and to the ability of work items to be linked together, which brings us to the next question.

2. which dependencies do we have between our work items? do we need to replicate any other dependencies in the tool, apart from the hierarchical breakdown?

3. what is our definition of done for a project or for a work item? do we need to have a certain scope completed, or is our project tied with the time elapsed? do we need multiple final states for work items (e.g. done and resolved)?

people

1. how are people organized into teams? do we have cross-functional teams? functional teams? project teams? departments? no teams at all?

2. is development process the same for each team?  do we sometimes need to assign several teams to an epic or to a user story?

3. does anyone need to be aware of how work progresses, even if they are not assigned to this team or to this project? customers? executives?

plan

1. how do we do backlog management? where are the backlog items coming from? how do we groom the backlog?

2. projects/releases/iterations: do we have cross-project (or cross-team) releases? parallel iterations or releases? do we break down projects into phases (e.g. ux, prototyping, functional design, delivery)?

3. which reports do we use? this one is very important. be sure to check if the tool has all the reports that you need.

the reason i give this list here is that sometimes people overlook some essential components of their development process as they commit to a project management tool. i’m not claiming that each and every possible question is covered in the list above, but the 3 checkpoints framework will help to get a more complete idea of the points to note about your development process when choosing an agile project management tool.