Diego Perdana – Product Manager Portofolio

In a startup company, Agile software development is one of the methods to develop features or products that can accommodate fast feedback and incrementally deliver the product. We also using SCRUM as a framework to help us manage our improvement task for developers or engineers that will be working on that. I think all of you already familiar with what is SCRUM, so let’s jump into the main topic in this article which is how we manage our Sprint based on my experience

Let’s talk about the Sprint more details. Based on my experience and other tech company doing, we divided the process and timeframe in each Sprint like this:

Sprint: 2 Weeks

• Sprint Planning: 4 Hours/2 Weeks
• Daily Scrum: 15-30 Minutes/Day
• Sprint Review: 2 Hours/2 Weeks (before sprint planning)
• Sprint Retrospective: 3 Hours/2 Weeks (after sprint planning and review)

Above is most of the tech company doing and it depends on which product behavior that we create.  I can say that because when we implement this 2 weeks Sprint, it seems like at the beginning it’s fine but we realize that our features are not only a standalone product or journey, but it’s a platform. I found a good definition from Google Translate based on the Oxford dictionary about what is Platform. The definition from the Space sector is a raised structure or orbiting satellite from which rockets or missiles may be launched. In my opinion, a Platform type product is the same as structure or orbit on satellite and other product services and data likewise rockets and missiles.

An example of a platform type product is the Search feature that I’m handling now. In Tokopedia, our search bar is not only using for searching data of physical goods but also a place to find Campaign, Digital Services (e.g buy Mobile Data and Voucher Game) and Financial Services (e.g Gold and Lending platform). Other than that our Search services also be used as microservices to other features and engines in Tokopedia. So based on that, we are facing the issue which is a dependency from other Squad or services that collaborate with the search.

For example in the middle of the sprint, we need some tech improvement from other squad because they use our engineering services and it’s urgent (based on impact and effort). We know that after sprint planning we cannot change the requirement but we realize that as a Platform, our users are not the only buyers that user search but also other Tribe that uses the service. So we need to reprioritize the sprint backlog and they need to wait after sprint review so the maximum is 2 weeks.

Another problem that we see is to enhance the productivity and discipline of our engineers. Our assumption that we can be more productive by doing a more tight deadline for each backlog in one development period time.

So based on the two problems above,  we try to build a one-week Sprint for our Backend Squad as our solution. This is the details:

Sprint: 1 Week

• Sprint Planning: 1 Hour/Week
• Daily Scrum: 15-30 Minutes/Day
• Sprint Review: 1 Hour/Week (before sprint planning)
• Sprint Retrospective: 1 Hour/2 Week (after sprint planning and review)

In this sprint one-week, there are some tips that i can share for doing like above and effective. In Sprint Planning, we only gather 1 hour because our backlog already has story points hovered by PM, Tech Lead and EM in pre sprint planning meeting. By then the other engineers in sprint planning only ask about the backlog details if needed and how they will work on it. In the sprint review phase, we only gather  1 hour because the task should be not much as 2 weeks sprint and we do it effectively (usually our engineer already prepare what they want to show until beta testing environment). For the Sprint Retrospective, we still do it Biweekly because when we tried to do it weekly, we don’t have stories or complaints again to share.

Conclusion

We already doing this One week sprint since three months ago and it’s going well. I’ll explain in pros and cons:

Pros

• The deliver its faster and less dependency with other squads because we can prioritize the backlog on the next week
• The engineering squad experienced more productive by doing this. (I remember there is one engineer in my squad can do 13 story point that usually we do in two weeks sprint)
• Push engineering and PM thinking and energy to the limit to deliver the feature on time.

Cons

• Product Manager needs to be more discipline to build the task and get an effective meeting to gather requirements. Because it’s one week, you only have 4 days maximum to prepare next week’s sprint backlog.
• If your products need to maintain the scalability and performance in tech or even involve big data processing and preparation, this one-week is not fit enough because it will make you a little bit rush to deliver it so you need to make sure your backlog is small enough (in terms of effort and phase) so the engineer can deliver it well in a week

I think that’s all from my side, i can say to choose one week or two weeks sprint is based on many factors and its preference for each tech squad in a startup company to choose. It can be based on your product behavior, company software development culture, engineering culture or others. Besides that, there is no wrong or right if it helps nurture your tech squad, company, product metrics and build good product development just try it and improve.

Thank you!

*Special thanks to my Engineering Manager (Harry) and Squad Tech Lead (Roberto) to make this happen.

Reference

1. Agile Software Development: http://www.agilenutshell.com/
2. SCRUM: https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ID.pdf