Sachin Rekhi

One aspect of startups that the ecosystem is getting better at is designing our startups for learning from our customers to find product/market fit. Steve Blank and Eric Ries helped popularize these notions and the ecosystem has embraced them.

But what I've found surprising is that these learnings haven't been readily applied to the development process and they definitely should be. From the earliest stages of a startup, the R&D team should be designed in such a way to maximize learning for improving the R&D process itself.

What exactly do I mean by this? Well, you'll often find that early-stage development teams are poor at estimating how long it will take them to ship a feature. Product teams also tend to be poor at estimating what the affect of implementing a feature will have on customer metrics. While this is always the case initially when a new group of people start attacking an unknown problem, the issue is I find that even teams who have been working together for years in the same space still seem to suffer from their inability to accurately forecast dev cycles and product outcomes. They are also unlikely to be able to improve upon engineering velocity and product outcomes in subsequent iterations in a predictable way.

To prevent this from happening I encourage startups to design their R&D process in such a way to facilitate learning. The most popular agile methodology, Scrum, provides specific guidelines for facilitating such learning, though they are typically not rigorously followed. The best practice here is to leverage both the sprint planning and sprint retrospective meetings at the beginning and end of every sprint to systemize this learning.

Sprint Planning
The sprint planning meeting occurs before the beginning of a sprint to plan what set of work the team plans to complete during this sprint. Items are picked off the product backlog and brought into the current sprint backlog and each meeting ends with a prioritized list of tasks and a commitment from the team to complete the set of tasks agreed upon in the meeting.

What's important to do here is to ensure each team member that will be implementing each task estimates how long they believe the task will take them. Make sure the implementing team member does this themselves as opposed to an engineering lead or someone else. Then write the initial estimate down next to each accepted sprint backlog task.

Similarly, each of the product owners that are encouraging certain features or sprint items to be implemented should estimate how they expect each of those features to move specific customer metrics and by how much. They should also write this down next to each feature being implemented in the sprint.

Sprint Retrospective
Now at the end of the sprint, in addition to the sprint demo, it's important to also do a sprint retrospective. Sprint retrospectives are designed to take a breather before the next sprint so that you can have a moment to think about how you can improve upon the sprint process in the subsequent sprint.

The key part to make sure you are doing is looking back on the initial engineering estimates and tracking how long it ultimately did take to implement each of the sprint items. The individual developers implementing the features should be involved with this. Estimates are never completely accurate and that's fine. But by implementing this process you can improve over time the estimation error. Since the developer who initially provided the estimate can now see how off he was, he can learn from that experience such that when estimating the next sprint, he can adjust his estimate based on what he's learned about his own estimation abilities. While this may sound simple, this step is often missed and unless an engineer is proactively sitting down and comparing his estimate to actuals every sprint, he isn't going to improve his ability to estimate in the future.

Similarly the product owners should be tracking how the features that have been deployed actual perform against their metric forecast. And similarly they should be looking regularly at the comparison between their initial estimate and actual metric movement to help improve their own forecasting abilities and improve prioritization and selection of work that will ultimately move the needle. This helps build strong product intuition by seeing the implementation of many features and understanding exactly what impacts they had on the customer.

So in your next sprint, make sure your team is getting the most out of your existing scrum process by fully leveraging sprint planning & retrospectives to help build every team members forecasting and intuition for development timelines and product outcomes. This will ultimately give you the capabilities your team needs to improve engineering velocity and product outcomes on a regular basis, which will significantly improve your chances of success as a startup.