How to Create the “Perfect” Workflow
“Perfect” is a word that most people tend to meet with suspicion. I have yet to encounter anything that is permanently perfect. It implies that no improvement is either necessary or possible. So let me define what the “perfect workflow” means. But first, what is a workflow and why is having a set workflow important at all, let alone having the perfect one?
What is a workflow?
When working with complex products, projects and cross-functional teams, it is critically important that work can be handed from one person (who has completed their part) to another (who is about to start their part) without missing a step. Sounds simple enough but when you add the complexity of each team member having a different specialist area, with different nomenclature, ways of thinking and requirements to get started, a workflow helps a lot. It ensures that there are guardrails to prevent re-work, and unnecessary back and forth and ultimately smoothes the way to completion. If the project plan sets the“roadmap”, then the workflow provides the checkpoints and service stations/gas stations along the way.
Why is it important to create a specific workflow?
“Work flow” happens whether you are intentional about it or not. Those working on a particular task will reach a natural conclusion to where they can contribute (either absolutely or without someone else being involved before they can continue). For the work to move on it must flow to someone else. The problem is, that what one person might deem as finished, might not meet the requirements for the person next in line. What one person might decide is enough information to get started, might only give part of the picture to the recipient of the tasks, as far as what they deem necessary. There may be extra steps needed to get it to where it needs to be. Or fewer steps to help it move along without bottlenecks. And if it is different every time or for each person, how is anyone to ever know where their work sits in the overall process?
Having a specific workflow feeds into the bigger picture of strategic alignment as well. And “workflow’s” often forgotten sibling — “information flow” ties the two together. Information flow runs through the whole project team, from the project executives and sponsors to the business analysts. Of course, not everyone needs to know everything (consider using a RACI to determine who needs to know what) but having the right flow of information means that each person within the multi-discipline team will be empowered to play their role with the project vision in mind. For example, understanding the problem, user/customer and solution will help discussions on how a particular feature should work, which, in turn, will inform how it is designed… which again, in turn, will inform how it is technically achieved. All parties that are involved in the building of the solution, should have the appropriate details (information flow) and be able to work on their contributions, at the appropriate time (work flow). Setting a specific order for work to pass through, with accompanying information, smoothes the process and gets the right things done as quickly and efficiently as possible — all while keeping it aligned with the project strategy.
The “Perfect” Workflow
The perfect workflow adapts to the project/organisational needs. It is a workflow that ensures information flows in collaboration with work packages, to the right people at the right time. It ensures that everyone involved can do their job with the right information, context and requirements of previous steps completed. It is adaptive to how the project may change but maintains the guardrails of keeping everyone on track and unblocked. It will be different for every project, technology, company size, industry and team composition. However, the core components remain the same, even if they go by alternative names or have steps in between.
In Consideration — An agreement that it should be worked on
When a story, task (or whatever term is used for the work package) is ready to be taken to the project team to start working on, it should be in consideration. There should be a few in consideration at any time and should follow in the order of the prioritised backlog. At this point, the high-level story should be prepared for a deeper discussion. Whatever the “As an X, I want to…” story states should be taken as the starting point for the conversation. A deeper look at the description, acceptance criteria and any other important factors should be prepared to be involved in the conversation.
In Analysis — An agreement on the details of what is being worked on
Once a story is “In Consideration”, a product owner, key stakeholders responsible for business outcomes from the project and the core project leaders should have a conversation about the granular details of the story. Business value, usability, feasibility, and user value should be discussed with those responsible for designing the story being clear on how it should work and how it will create those types of value. Those responsible for building it should clearly understand what is technically required to create the outcomes discussed. Once a story is ready to come out of analysis, the designer should be able to complete the designs needed for development with few to no questions. This step often decomposes or creates new stories, which will need to go through the workflow again from the beginning (including prioritisation).
In Design — An agreement on how it should look, work and feel
A story in design should have all of the high-level business questions and granular technical/UX questions answered. The designer, (whether for a physical product, software product or something else) will have all the information they need to complete their work. At the end of their contribution in this phase, there should be a full set of designs with links between each step of the use case it is designed for. This will add to the improved and more detailed description and acceptance criteria that have come out of the analysis.
Ready for Development — Agreement that is ready to be built
At this point in the workflow, the story is ready to be built. It should meet the criteria that you set for “Definition of Ready” (as given in this example in a recent LinkedIn post). However you decide to define this stage, those executing the build should have everything they need to start and finish their work with minimum fuss.
In Progress — Started to built and still being worked on
It is important to distinguish between what is ready to be worked on and what is currently being worked on. This includes things that have been started and paused in favour of something else (maybe due to a blocking issue). Managing how much your team has in WIP (work in progress) and setting WIP limits helps to get work through the workflow without any single engineer hogging all of the work without actually completing any of it. It also encourages engineers to find a solution to any blocking issues (or the project leader to facilitate one) rather than just parking it and moving on to something else. The only way to get something out of WIP is to either put it back to “ready for development” for someone else to be able to work on or complete it.
Development Complete — Finished being built as far as those building it are concerned
This is an interim step/checkpoint. Those responsible for executing need a punctuation point where they can hand off to someone to test against the earlier criteria. There are sometimes smaller checkpoints within this. For example, a peer review might be implemented before the story goes to official testing by a quality assurance engineer. Whatever the case, there should be clear universal requirements for the engineers to be able to definitively say that they are done (not “done done”).
In Testing — Checking that what has been built works (and doesn’t break anything else)
Part of the definition of done should be that the story has been tested (and passed the tests). It is good practice for this to be executed by someone who wasn’t part of the build to avoid any blind spots. The person testing should be able to test without affecting or being affected by those still building other stories, so a stable (separate) environment dedicated to testing might make this easier. The testing should include testing that the new story doesn’t break anything that has already been through the workflow and is part of the final output.
The information flow should continue through to the tester as well. All of the information gathered during consideration and analysis as well as the designs and the details of the implementation should be available to the tester to cross reference, ensuring alignment with the spirit of the story and broader goals. To get beyond this checkpoint, the story should not only work, but not break anything else that was previously working and align with the broader objectives outlined in the desired-state solution.
Final Sign-off — Agreement that what has been built meets the goals that it set out to
Often shown in a demonstration at the end of a sprint, one of the final checkpoints allows the project leadership and senior stakeholders to review what has been done against what was discussed during consideration and analysis. At this point, everything has been built and passed testing so those responsible for sign-off will give the thumbs up to move it across to being complete. Like testing, this should be someone independent from the build process, so as not to bias the outcome.
Done (as in “Done Done”) — Work is complete
Actually done. Whatever your “Definition of Done” might be, the story achieves this. It is ready to be used by the intended user/customer and there is no work remaining for them to get the intended utility. It is now “done done”.
*Deployed/Handed Off — Completed work is ready to be used outside of the project team
There’s a checkpoint after “done done”? Well, this isn’t technically a checkpoint but rather a step considering the holistic view of the story in the overall project's desired outcomes. These stories don’t (or shouldn’t) exist in isolation. Just because they are done, it doesn’t mean that they are immediately useful. Whatever is needed to integrate this story into the final outcome should be clearly defined. This final “checkpoint” should signify that everything that needs to be done has been done to add this contribution to the overall effort.
Conclusion
The “perfect” workflow doesn’t exist. That being said, the checkpoints above set the structure for a workflow that ensures the right information flow and puts every team member in a position to win and maximise their contribution in the minimum time. Perfect means adaptable to the team’s requirements whilst meeting the project objective and encouraging alignment with the broader strategic objectives. Putting in the right checkpoints will go a long way to getting you to “perfect”.
