[English Blog] How Cho Tot Team Runs a Planning Session

In late 2019, Cho Tot team starts to apply some best practices into estimation and planning. It’s time for a retrospective to look back and review what team has achieved. There are also some key lessons during couple sprints. Let's get started.

Background

Most of teams have worked with Scrum for long time ago, it’s not actually a Scrum, it should be “Scrum But” instead.

We’ve built scrum team with product owner and development team (unfortunately, we don’t have any scrum master). We have followed series of consistent Scrum activities, such as sprint planning, backlog refinement, daily standup, sprint review and retrospective.

In fact, we also got many problems.

• Estimation: it’s our first biggest problem. As a good practice, all user stories have been broken down; however, we estimate on each individual task instead of a user story. As a result, all we have is a task estimation (not a user story estimation). It’s quite difficult for us to identify timeline for releasing a feature.
• Delivery : Stakeholders ask many questions about feature release timeline; however, it’s not an easy task to inform when a feature can be delivered. All we have is an estimation for separate task. At the end of sprint, we (unexpectedly) realize that we had missed some important tasks and the feature cannot go live!
• Self-organizing team: As traditional management principles, team members tend to follow what they are assigned from the top, and just try to complete their “to-do” backlog. A self-organizing team evolves from team members participating actively & collectively in all the Scrum practices and events. They have the autonomy to choose how best to accomplish their work, rather than being directed by others outside the team.

Several months ago, our managements stay together for a Product Cadence Review. During that session, we inspect, investigate root causes and brainstorm for actions.

Outcome

Let’s see the burn down chart before we apply new estimation techniques. At that time, we did the estimation as individual task: each team member raises their estimation on their own task, without challenge/question (since folk just cares their own assigned).

burn down chart

Then, we started to apply Scrum estimation techniques. Unfortunately, the 1st sprint is not better than before at all. There are two root causes:

• (1) Definition of done (DoD) — we agreed that a “done user story” means it’s ready on production. However, we build things as a whole feature, a single story cannot be released until the whole feature complete. Although a story had been completed (with developing and testing), we cannot mark it as done since DoD violation.
• (2) Individual task — we cannot drop our old behavior that running team with individual assignment. For example, a user story is broken down into 3 smaller tasks — 2 for backend API services and 1 for frontend integration these API to UI. The backend engineer then just focus on their 2 tasks, and frontend engineer too. Therefore, the following burn down describes our result.

In retrospective session, team sits and inspects those issues. We’ve discussed on what we can improve:

• Redefine team DoD: as our culture, we do agree and transparent that “Done” means complete a user story with testing. Production or Staging environment is removed from this DoD — As I said, since it depends on feature’s requirements, some feature requires to be released only if all high priority stories completed.
• Create a “Technical user story” for integration testing: before release a feature, we create a technical user story for testing again the full flow, to make sure all user stories are combined well.
• Revise and improve the estimation: focus more and more on user story, not individual task.

Moving on to look at following burn down for the 2nd sprint and 3rd sprint:

We keep monitoring the Velocity Report to see how our Scrum Team has improved.

What is velocity?

It is not just about complete a user story, it is about delivery things. In each sprint, we always keep practicing to set the sprint goal — to define & transparent which features to be release within sprint. I am proud to say that most of sprint goals are delivered.

User story estimation instead of individual task point

Deep diving into techniques for estimation, key important factor is focusing on user story estimation.

Why don’t we estimate as a task:

• Complete a task doesn’t mean complete a user story.
• We may forgot and miss some important tasks while breaking down user story.
• Estimation by task cannot cover complexity and risk of user story.
• Some tasks may be blocked by another tasks.

Benefits of estimating user story:

• More feature focus: team have a direction to focus more on feature and delivery.
• More ownership: team member who is assigned user story does their best to complete this user story, including chasing others for getting done dependencies.
• Sharing & transparent: the whole development team can provide feedback, ask question and challenge each other. For example, when the estimation shows with 3–5–5–8 points; then 3 and 8 have to explain and be challenged by others. Especially, the whole team may discover “unknown” things during this activity.
• Support MVP: a feature may have many user stories. With a MVP, we do not need to deliver all of things. Therefore, with a list of prioritization and corresponding estimation, product owner may have more insight to drive product experiment.
• Timeline information: much more easy to come up with release timeline.

Important notes for user story estimation:

• Listen for feedback from all sides: including requirement complexity, design availability, backend, frontend, especially testing and deployment. Some user stories are very easy to develop, but testing effort is so terrible — it’s not only testing time but also means engineers have to support bug fixing.
• Be careful for dependency: there is a type of user story which has tasks from many engineers/team/department. For example, a user story with backend API from team A, integrate frontend from team B, deployment tasks from team C. Let’s includes these complexity into your estimation.
• Time box: set a time box for each estimation round. We can encourage team member to raise their feedback and quickly moving to next round. Staying long time for a user story may broken planning session (people feel tired, many user stories are missing, etc…)
• Do NOT assume: if you don’t know what it is, said you don’t know. Don’t provide a blind estimation.
• Estimate as a whole team: final decision on user story point based on whole team agreement. While estimation session, do not force and bias others follow your point, instead, share with them why you throw out this point.

A self-organizing team

As Scrum principles, development team works as a whole team, not a manager and team members. Actually, there is a trap that an api service (as language by our engineer) is owner by only a person. Although a user story is estimated by team, it always be assigned to this person only at the end of the day. Image a scenario, a member submits leave for personal matter for couple days, then what happen?

Manager and leader work in team as usual team member, with a special role extra: can manage others. With this mindset, team member starts to build a very good behavior, this is “ownership”. They manage to get the user story done, keep running and chasing to solve all dependencies, communicate at early stage when any problem happens with their assigned.

While planning session, don’t forget to go through one by one individual to-do backlogs. With this practice, team can identify if any member is overload or under-capacity. There’re many volunteer to pull (not push) user stories from overload to under-capacity. It’s awesome.

Flow

Here’s how we manage to a successful sprint estimation:

1. Be ready for requirement: this is product owner’s responsibility. He/she must collaborate with stakeholders to define Product Roadmap from high level requirement to details (not high level only). The more detailed user story, the more accurate estimation.
2. Backlog refinement: don’t bring user stories into sprint planning without feedback from engineer. If engineer doesn’t have enough time, just make sure story is reviewed and feedback by team leader. This habit can fulfill requirement missing, also, team leader may aware and identify things to prepare and risk.
3. Task break down: make sure user story is broken down into small tasks before estimation. While breaking down, team also identify level of complexity of a user story. Broken down session also opens door for development team to get more knowledge and understanding about feature.
4. Estimation: play a scrum poker game to come up with user story point. Don’t forget to set time box for estimation session .
5. Define sprint goal: ask product owner to priority backlog careful to make sure important things to be developed and released first. With this goal, development team then scope down what they estimate can be delivered — based on team velocity.
   For example, team velocity is 40 points. Then we should remove all low priority user stories to make sure total point is around 40 (actually, it can be higher or lower, depend on team’s confident).
6. Go through individual to-do backlog: to make sure no overload and no one free. Team can discuss and share user stories, but make sure all team members feel happy with this decision.
7. Naming sprint: just for team easier to remember the moment. Encourage team member to innovate a name, it’s a fun activity!
8. Build plan & release plan: after planning session, development team review sprint backlog, discuss and come up with build plan and release plan. By using those, we can identify timeline for testing, review and deployment.
9. Daily catch-up: estimation is still an estimation, therefore, any issue should be raised at early stage to make sure sprint goal is not broken. Especially, during a sprint, if development team feels that their estimation needs to modified, don’t hesitate to make it. However, sprint backlog (sometimes, including sprint goal) also needs to be reviewed or modified accordingly.

Conclusion

Don’t be afraid to failure. Be afraid of not learning from failure.

Apply new techniques is never an easy task; but if we don’t try, we never know how strong we are.

Keep listening for feedback, inspect and adapt.