Product Development Workflow
What I will be sharing below might not be the industry's best practice, but at least it is a software development workflow that works for me for the last couple years.
Last updated
Was this helpful?
What I will be sharing below might not be the industry's best practice, but at least it is a software development workflow that works for me for the last couple years.
Last updated
Was this helpful?
This time, I'm not gonna talk about project management methodologies such as waterfall versus agile. So I would assume you are already familiar with sprint-based development model. Therefore, we will more focus on what could happen inside a sprint.
I will not cover the Design part of the sprint in this writing, because it actually deserves an independent title to write about. Also, the Quality Assurance part of the sprint deserves a standalone title for in-depth discussion.
Definition of Done (DoD) is a very important term that must be agreed upon by the team members, even before starting the very first sprint. It answers to the question of "What does completed tasks look like?". Because it could be meant anything, to name a few of the applicable task status; Development Done, QA Passed , or Ready to Release, you decide.
In this writing I'll use Ready to Release as our agreed DoD. It tells us that, for a task to be claimed as completed or done, its status has to move all the way from To-Do to Ready to Release by the end of the sprint.
Now, let's talk about what could possibly happen between those two status inside a sprint. Although it would vary from team to team and product to product, at least these things are the ones that work for me and my team.
Sorry to keep you waiting. Before we jump into granular level, I'd like to share that as a PM, I usually use a simple Kanban Board for helicopter view to monitor the sprint progress with my Tech and Design leads. This partly because I'm not aways have the privilege of using advance project management tools such as JIRA, therefore I'd create this Kanban Board either using Trello or a simple GSheet to get a glimpse of how my team is doing within the sprint.
I would say Kanban Board is a simple task progress tracker that divides items into Backlog, In Progress, and Done cards. Let's talk a bit of each of them below.
Backlog is the list of tasks that will be picked up in that particular sprint by the team a.k.a To-do List. There will be Backlog Grooming and Sprint Planning sessions for the team to decide what to be worked on within a sprint, I will discuss about these next time.
In Progress contains all the tasks that are currently being worked on by the team. Meaning, team will move a task from Backlog to In Progress when they decided to start working on it. We will talk more details about this in the following section.
Done is our dream land, it includes all the tasks that has met our DoD, thus it won't be carried over to the next sprint.
Well, as you can see there's actually a lot going on inside a development sprint. I use the workflow above for most of my product development projects. Although, I have a simpler and even more complex versions depending on the product nature and scope. Let's discuss about each of activity mentioned in the picture, but we can skip the start and end parts, as we have talked about it in the previous section.
In Progress; it has a literal meaning of development in progress, the so-called coding or programming works. Team should move the task item from To-Do to this card, when they decided to work on it. So that everyone knows it has been picked up by whom.
Implemented; all the tasks that have been coded or programmed according to its details and acceptance criteria could be moved onto this card. But you can say that it is still in a Draft state, as it has not reviewed and tested by the responsible team, yet.
In Review; once a task has implemented by engineer, there will be 1 or 2 other engineers who will perform code review out of it. This is to ensure that there is no error found in the logic or potential pitfall that could cause loophole in the functionality, or even security. Additionally, it could be done to assess whether the written codes are easy to understand by other engineers. If the codes failed the review process, it should be returned back to In Progress to be revised according to the reviewers' remarks.
In Testing; when the implemented code found to be acceptable, it's now the time for Quality Assurance (QA) testers to perform thorough testing against it, on the functional level. Prior this activity, in the beginning of the sprint, QA team will usually prepare a set of test cases that is derived from the development task details, covering both positive and negative scenarios.
To Be Confirmed; in reality, the output of system testing is not always a clear Failed or Passed declaration. Sometimes, there will be ambiguous system behaviour or use-case found by the tester, that was not clearly defined in the task detail. When this happens, it's always better to flag this finding as TBC instead of plain Bug . This is to ensure that engineers do not rework on something that should not have to be fixed. It's PM's jobs to give confirmation whether it is indeed a bug or can be postponed for next sprints.
Bug Found; this card contains all the tasks that have not passed the testing stage. What I usually do with my team members is to create a sub-task for each of the bug found, positioned inside the main task. The benefits of doing this are 1) it's easier for the team to track each of the bug's status, 2) team could work on one bug at a time, just imagine if there's 10 bugs produced from one main task, and 3) it's also easier for us, PM, to prioritise which bugs to fix first.
In Revision; similar to In Progress stage, engineers team will pick up the sub-tasks from Bug Found that need rework or revision. In some cases, team will need PM to give more clarity and details on how to solve the issues (set expectation).
In Verification; once a bug is fixed, QA testers will perform re-test to that particular issue, to verify whether or not it can be considered fixed. If turned out the problem still exist, QA team will re-open the item and move it back to Bug Found. Please note that it's not a rare phenomenon for QA testers, when they are verifying an existing bug, to find another bugs along the way, please be ready 😉.
Bug Fixed; if all has been verified and is considered fixed, the QA team should move all the bug items and its parent task to this card. Usually, toward the end of the sprint, they will perform final testing to re-check all the test case scenarios before marking them as Ready to Release and move them to Done.
As you have read, there's a lot going on inside a sprint. Regardless if it is a 1-week or 4-weeks sprint, the sequence remains the same. That is why I combine the Kanban Board and the Sprint Board so that I could still get overall progress without micro-managing the team, but also without sacrificing the technical details and processes necessary to deliver quality products.
The naming convention for each card or status mentioned above is not absolute, it is really up to you and your team to decide together. Just make sure that everyone has the same degree of understanding on "what is what", and do not forget your Definition of Done.
Lastly, for a task or sub-task (bug) that somehow could not be completed in the current sprint, it should be carried over to the next sprint. We, as PM, then need to re-evaluate the priority of those leftovers tasks against the backlog we have already planned for the next sprint. This is to decide which one the team should work on first, because the level of importance of whatever tasks we have in our backlog could change rapidly in today's work environment.
Thus, it is our job to make sure that our team is working on a set of tasks that will bring the biggest value and potential impacts to the company in that particular timing. Let's discuss more about this in the next writing. See ya!
