The dev flow is great, but what about the requirements flow?
How to design the requirements specification flow in a small startup
You are a small startup, you have a dev team and you did a great job with that process architecture and your dev flow is flawless :) (if still struggling, may I suggest you take a look at my blog post Kanban board within GitHub — a simple solution for small startups). But when talking about the software development process, we often just assume that a task/story somehow ends up in the backlog and is ready for implementation. Just as we have the process to implement a feature, we need a process to specify it. I am a huge fan of Kanban alike boards with lists/columns/buckets (again, check Kanban board within GitHub — a simple solution for small startups), and I simply use the same practice on the other side, when working with the startup founders, product owners etc. There are various tools that can be used, one of them being Trello — a simple, flexible, intuitive solution and also very well accepted by non-techies.
Here is how you can arrange the lists:
- Bugs — a place to report bugs in live application
- Backlog — anything that comes to a creative mind
- Elaborating — these are the backlog items we want to specify further. Here is where the comments and questions are left, where the product manager would ask the founder for clarification, or get back with the questions/answers from the dev team. We stay here until the feature requirements are clear and we are all on the same page.
- Prioritizing — this is where a well elaborated feature with the effort estimation from the dev team goes. Here is where the decision makers (founders, product owners and alike) will take a look and stick one of the priority labels (such as Low, Medium, High). Suggestion: use the labels for the effort estimation as well, makes for a better visual overview.
- InImplementation — this is where the magic happens :) The high priority items go here to be implemented. Don’t forget to re-prioritize so that there are always items ready for implementation. For the implementation flow, check again Kanban board within GitHub — a simple solution for small startups.
- ToAccept — implemented features, deployed to the staging environment.
- InUserAcceptance — move the items here while you are checking them out in staging
- UserAceppted — after giving it a go in staging, hopefully the item lands here. Otherwise back to the lab (InImplementation).
- Delivered — deployed to the production environment, live
A few notes:
- Now that you are familiar with the flows on both sides, note that it’s the product manager that jumps from own side to another (remember we’re talking about small startups where the product manager is in the same time the project manager and much more). My plan in the next few days is to experiment with a zap from Zapier, to automatize the GitHub2Trello part of the flow. Will keep you posted on my progress.
- It’s a good practice to have links to GH issues in Trello cards.
- Pay attention to bottlenecks — the lists that seem to get more full by the day, or that stay empty for too long. For instance, if the Prioritization list is empty, you might not be doing a very good job elaborating the new features. Or if InUserAcceptance is the fullest one, maybe somebody needs to find some time in their schedule, get to this and stop blocking the delivery :)
- As I mention in How to Scrum with freelance teams, the development process will attempt to iterate, aiming at delivery every second Thursday (just an example). Try to keep the requirements flow shifted by one iteration, meaning that the requirement flow for the next development iteration is happening while the current development iteration takes place. This is crucial to prevent the situation when after the delivery you have an idle dev team waiting for the new requirements.
Good luck and go with the flow! :)
I help startups set up their software product development. Lean, agile, remote. For more info, reach out at www.tijanamomirov.com
