My First Jakarta Scrum Meetup

A few days ago, my friend Hugo invited me to a Meetup in Doku’s office. We all very excited to learn more about scrum. We split into groups to focus on a specific topic. I took part as the facilitator for a group, which is focusing on “How to run scrum in software development service company”. Surprisingly, almost 20 persons enthusiastically joined the group 😊

Scrum Meetup — Feb 22, 2017 @ Doku’s Office, Jakarta

There were a lot of issues on this subject, so we decided to focus on the top most issues. First of all, participants put their question in a note, then order question priority by voting on it. In short, we made a PBI (Product Backlog Item) or should I say, QBI (Question Backlog Item) 😁 For each question, we discussed it and try to figure out as many perspectives as we can.

We have more than 10 questions, but since the beginning, we knew that the time won’t be enough to finish it all. At the end of the session, we managed to answer 4 of it, and here it is….

#1: How to handle customer (Product Owner) that don’t even understand what they want to build?

We can’t build what we don’t understand. Even tough we do it, we’ll suffer to unpredicted changes. Scrum help us adapt to changes, but it doesn’t mean we can build something that we don’t even understand.

Before starting a sprint, do a grooming (backlog refinement) session. Break big requirement into smaller requirements. This way, we break the problem into smaller and manageable issues. Define how each issue related to another one. A smaller requirement is easier to understand and relate. For example, we can define the whole business process using Cross-Functional-Flowchart (swimlane) or Activity Diagram. Break it into several processes, go deeper to each process until we have enough understanding.

In waterfall approach, we do this in the assessment phase. In waterfall, good assessment really important, since it will define the scope of work for the whole project lifetime (eg. 6–12 months). It is also important in scrum, to enable Development Team deliver useful items during next sprint. It is also important to let us have more accurate task estimation.

#2: How to estimate feature or task size when we even have no idea how to build that?

When we estimate item size in PBI, there are 3 things to consider:

Effort: How many things to build?
Complexity: How difficult it is?
Uncertainty: How many unpredictable factors identified?

Size = Effort + Complexity + Uncertainty

From my experience, a developer will need 4 (four) times longer to create an application when they need to learn the technology. This is applied for new technology adoption, for example when a .NET programmer should create codes in Java. But, some complicated problem needs certain level knowledge. We can’t just put a bunch of non-experienced programmer with lack of logical skill to develop rocket launching software 😝

Whenever possible, try spending your time to do research on how to build the feature. Break the feature into smaller functions, some functions will be obvious to build, while the other not. For the difficult part, try to build it without considering performance or efficiency at first. Use it as the worst-case scenario. Along the way, find another alternative, which is more efficient than before. If necessary, put the “research” as an item in PBI.

#3: What should we do when customer insist for a specific deadline?

First of all, every stakeholder should understand that in software development, every phase is a design phase. In manufacturing, we design the product upfront, then do “mass production”. Mass production means we create the same thing over and over again. In software development, requirement-design-code-test practically is a “design” activities. Development Team doesn’t make same exact things, over and over again, because every feature is unique.

In scrum, we split development activities into time-boxes called sprint. We can do some kind of estimation to manage our expectation or at least to make sure that every sprint has equal weight. PO should define a PBI that consist of all expected deliverables (business and architectural), ordered by priorities. Scrum Master facilitate Development Team to estimate PBI items size, then define their own velocity.

If PO, SM, and DT agreed that item size and velocity already make sense, then the number of sprints is just a logical consequences.

Total Sprint = Total Size / Velocity
Tips: we should also add some buffer for rework and changes

It is important for every stakeholder to understand that estimation accuracy is the key. If somebody try to cut item size just to meet the deadline (or sometime to cut the budget), the estimation would be useless. It will finally end up in overtime for the development team. End up in stress for the PO, when he finally knew that adding more programmer at the injury time won’t make it delivered on-time.

If expected deadline earlier than total sprint duration, then we have 2 alternatives:

First, see how many items could be delivered within the deadline. For example, we need 10 sprints to build 100 items in PBI. If the deadline is on the 8th sprint, then we could commit to all deliverables from 1st to 8th sprint only. This is possible because items in PBI ordered by priorities. Since items in sprint 9th and 10th have lower priority, there are possibilities that the application could go-live without those features. We can deliver remaining feature in the next release.

Second, add velocity by rearrange team composition or dispatch more than one team. This is possible when deliverables can be done in parallel. We should be careful when an item is a prerequisite to another item. Another thing to consider is some items could not be done faster by adding more people doing it in parallel.

#4: Could PO add items during a sprint?

No. He could not.

Scrum Master have 3 (three) key roles, which are Process Coach, Problem Solver, and Protector. Sprint is timebox for a committed scope. Scrum Master should be able to protect the Development Team from scope modification during sprint runs.

PO may add or change items for the next sprint, not for the current sprint. If Development Team able to deliver all items before sprint finished, we should close the sprint at that time. Timebox means we may not exceed committed time when the items have not done yet, but we can stop it when we delivered it faster.


Due to limited time, there were many remaining question unanswered. I hope we can discuss it some other time 😊

Like what you read? Give Ahmad Firdaus a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.