In Part 1 of “How to Manage Product Organizations” we closely examined the Discovery workflow. More precisely, how to innovate the right way, the best product teams structures and the step-by-step system for discovering/identifying the highest value features for your product.
In this blog post, we’ll go one step further. We’ll show you the best way to organize the building of your validated/confirmed features. Once again, it’s important to note that even if you don’t have a technical background, the tips and tricks in this article will help you execute effectively and manage for results.
Now, without further ado, let’s jump right into it.
Delivery Workflow Step 1 –
Setting up Your Sprint for Success
When the Discovery team has validated what features need building, the next step is to send those features to the Delivery team – to go in a Delivery sprint. Tasks are created in the project management tool of choice – for example, Trello, Jira or Linear. Ideally, the Product Manager (PM) or the Engineering Manager (EM) should be responsible for the creation of these tasks.
Usually, the task descriptions must be very thorough, containing at least the sections:
- Why are we building this feature?
- What needs to be built?
Providing ambiguous requirements is an easy way to demotivate your team, and also to get results that do not match your intentions. Having designs goes a long way of resolving this problem. Ideally, at the beginning of the sprint – there is a Sprint Kick-off meeting with the entire Delivery team. This is usually a longer meeting, between 1-3 hours. You can split the meeting over two days if needed, but don’t rush it too much.
The goal of this meeting is to review each of the tasks and clarify anything that is not 100% clear. Another very important goal, of course, is also to estimate each task. A great way to do this is to have the estimations measured in story points. It works like this:
1 story point = expected 1 day of work for 1 developer.
The developers together must propose the estimates (as a discussion in the meeting). Counter-intuitively, people tend to underestimate things slightly, not inflate the estimates, probably because of the peer pressure that happens automatically in a meeting.
Handling Project Estimates
Sometimes (oftentimes), an estimate is significantly bigger than what the non-Engineering stakeholders expect. In that case, it is normal from time to time to discuss an estimate to understand why something will be so time-consuming. This will allow the team to cut down on some of the feature scopes that contributes greatly to the cost without bringing much value. Moreover, it will allow you to avoid misunderstandings about the scope of the task. Knowing the estimates of the different tasks allows the team to put in the sprint the right amount of tasks. Usually, the team works in a fixed Delivery Sprint length, such as 2-week sprints (for most early-stage products).
Therefore, it is important to know how many tasks to put in the sprint. The main reason why Delivery teams work in sprints – is because the scope of the Sprint gets locked in at the beginning of the sprint, and other stakeholders cannot change the scope of the sprint until it is completed. The only exceptions could be in very rare cases, such as when a critical bug occurs that needs to be pulled with high priority into the sprint.
Delivery Workflow Step 2 –
Accountability During The Sprint
Once the sprint’s scope is decided – there are Daily standups. Having at least 3 to 5 standups per week for newly established teams is strongly recommended. Those meetings set the accountability and ensure the progress of the sprint.
For the best advice on how to organize and execute your standups, check out our article on how to manage developers for non-technical managers – section “The Most Important Thing – Team Standups”
Other than that, within the sprint, there are precise steps for the tasks to go through – represented by columns in the project management tool of the team (e.g. Trello; Jira). Here are the steps outlined below.
- To Do – containing the list of tasks for the sprint.
- In Progress – tasks that a developer is working on.
- Code Review – tasks where a developer has completed the coding, and now another developer from the team needs to review the code to ensure its quality.
- Manual Testing – the developer that has built a task should have tested the feature they built. But maybe they didn’t think about some of the things that needed testing (“edge cases”), or they didn’t understand the task’s requirements correctly. Therefore, it is a good idea that the person who assigned/wrote the task specification (e.g. the EM or PM) does manual testing of the feature. Does the feature successfully do what is needed?
- Testing passed – accumulates the list of tasks that have passed manual testing and now are waiting for the next Production release.
- Released – accumulates the list of tasks that have already been released to Production.
There is one more critical process to establish in your Delivery workflow. Whoever is responsible for a particular step has to move the task to the next step once it has passed their step (in the project management tool).
How to Do a Production Release?
At the end of the sprint, the tasks that have passed manual testing need to be released to Production. Those tasks are currently on the Staging environment, which is just a copy of the Production environment made for testing purposes. This means it is a separate URL with a separate Database, separate code and so on.
Before starting the release, it is best practice to test everything on the staging environment once again. This is usually done by the EM or PM and is called “Regression testing”. That’s done because one new feature may work in itself, but it may have broken something completely different in the code – for example, your sign-up flow. As a rule of thumb, test (at least) that the most important features are working properly – such as the sign-up and sign-in flows, etc.
When the Regression testing is passed on staging – the developers in the team start with the release. For our stage (at RemoteMore), a Regression test takes between 1 to 3 hours. Often there is some back and forth about things that need to be fixed. Then the release to Production itself may take 1-4 hours. Once the code is live in the Production environment – ideally, you should test it again on Production. That is usually done by the EM or PM, and you can call it “Regression testing on Production”.
Once everything is confirmed to work correctly on Production – the last step is to write the release notes. The aim here is to inform your stakeholders about what was released and keep everyone up to date. 🙂
Final words
Congratulations on making it so far!
If you already read Part 1 (about Discovery workflow), you’re now ready to build and manage your top-performing Product team. Needless to say, the tips and tricks outlined in both parts could be used for both remote product people and on-site people.
If you’re wondering where to find skilled remote developers with very competitive/affordable salaries, you don’t need to search any further. You can sign up to RemoteMore today and browse, message and interview thousands of pre-vetted developers completely free.
Good luck and have fun!
P.S. Interested in some of the parts of this topic? Our CPO would be happy to talk about it. You can connect with him at boris.borisov@remotemore.com.
