You just learned about scrum and feel confident to start your Sprint Planning session. However, what exactly does Sprint Planning consist of? How do we decide what features are going to be built in the current sprint? What are the outcomes of a Sprint Planning session?

Before I start talking about the Sprint Planning process, I would like us to take a step back and look at the big picture. Instead of focusing on one sprint, lets focus on the product that we are building first. This is so that we know what we are working towards after the completion of multiple sprints.

Every product that a company build is paid for by a particular user. Therefore, before doing any planning, we first need to revisit who our users are. This is because if we start deviating from their needs and wants, they will eventually look for a close substitute.

What are Personas?

Personas help us understand the user's needs, wants and goals. By creating the persona, we understand who we are building the product for. Using a very basic Airbnb as an example, we can start with 2 personas, a home owner and traveler. The smaller the company is, the more specific the Personas are. A product is usually niche at the start, but as they flourish, the characteristics of the personas becomes broader and cover a wider audience. Some companies grow so big that they do not see the need for Personas.

However, my personal opinion is, it is always important to revisit the persona to understand your core audience. This is because if you have been playing the game of business long enough, a close substitute will eventually come along. When this happens, it is natural that some of these users will flood to your competitor's product. On the other hand, if you do things right and meet the needs and wants of your core user group, they will stay.

An example of this will be Instagram. Instagram targets people generally below the age of 35 who want to share great photos or story moments with a certain network. When TikTok emerged, those who use Instagram to create content or skits flocked over as they are their targeted user groups. Only by understanding this, you realize that Instagram and TikTok are not really true competitors as they target a different set of audience. However, because TikTok did not exist before 2016, these creators did not have a choice but to use Instagram.

Yes, yes you may say Instagram should have identified these persona's earlier and perhaps adjust their product to cater for these users. However, we won't be debating about this, but this is why it is important to constantly conduct user research to understand the demographics of the users and what are your users using the product for. UI/UX researchers are usually the ones creating and refining the personas from time to time to ensure that they accurately represent the current users of your product. Only after understanding our users, we can then start to plan out our initiatives.

Breaking down the Initiative

Whenever the team wants to build something special, you will need to draw out some kind of game plan. One of the most popular ways to organize your work is through initiatives, epics, stories, task, sub-task. This is a very user centric approach as each task completed will satisfy some of the user needs and wants.

Some of the popular project management tools includes Jira, Click up, Notion, Asana and Monday. All the different products have their own advantages and limitations which we will not discuss. However, from my personal experience, it is better for a company or team stick to a single tool, meaning to say if one team uses Jira, the rest should use it too. Or else managing scaled up scrum where one team is using notion and another is using Jira will turn into a nightmare.

Lastly, before we start any sprint planning, the team needs to decide and have a common understanding of the Definition of Done.

Definition of Done

A huge caveat before we proceed is that according to the scrum guide, the definition of done should apply for every user story. However, from experience a Design Task has a very different acceptance criteria from Developer Task or a Quality Assurance(QA) Task. At the end of the day, the team must have a common consensus on the definition of done for the different kinds of task. This is so that when a task is marked as Done, the team all have a common understand what each task has gone through.

An example of a Design Task may be to conduct AB testing on 2 different designs. The definition of done of a design task may include:

1. Create 2 variations of a design of the particular page each following two different sets of design principles
2. Conduct user research on at least 3 users
3. Draw a conclusion on which design to choose base on the supported evidence

An example of a QA Task may be to investigate a particular bug report filed by one of our users. The definition of done of a QA task may include:

1. Replicate the bug on staging environment
2. Create a Bug report
3. Fix the Bug
4. Write a unit test for the bug
5. Release the bug fix to staging
6. Test the bug fix on staging
7. Release the bug fix to production
8. Inform the users that the bug has been fixed

An example of a Developer task may be to create a login page. The definition of done of a developer task may include.

1. Create an approve wireframe for the task and for the different user flow
2. Write the necessary unit test for frontend
3. Write the necessary unit test for backend
4. Write the necessary integration test to ensure that the feature work
5. Pass performance testing
6. Pass penetration testing
7. Pass QA
8. Pass Code Review
9. Write the necessary documentation
10. Release to Staging
11. Pass QA Staging
12. Release to Production

Sprint Planning

Now that we have talked about the different terminologies, it's time talk about the Sprint Planning session itself.

At the start of the Sprint Planning meeting, the team needs to decide on the what. The product owner pick items from the backlog that the team will be working on and sets the initial sprint goal. These items are usually picked because they are related to the initiative and epics of the previous sprint or because are starting a new one.

The development team will then plan out the how, or the scoping and specifications needed to deliver the sprint goal. It is important that this process is a negotiation, if the work is too much, we need to adjust the what. But at the end of the day, the scope of work must be manageable and the team must agree that the items pick can meet the definition of done by the end of the sprint.

Once the sprint goal is finalized and the scope of work is final, the team then decides the who, in other words who takes which task. This process is done purely by the development team.

In most companies, the how portion is where most controversies arise. Don't worry if it turns into a negotiation and tensions may arise. Good teams will know how to use this tension to make the product better. This is because everybody is thinking for the product itself, and a simple task may become very complicated if done correctly to make it future proof.

There are also companies that run the top-down approach where bosses just say, I don't care how, just complete this set of work within a given time. This is where you start to build products in the fastest way possible almost as if you are back in a bootcamp. For short lived projects or products that mean to last 1 to 2 years max that are only used by 100 to 1000 users you will be quite safe. However, for project maintenance and adjustments, it is likely that just by reading the code, you will want to jump off a building.

In my opinion, the top-down approach is what is causing the great resignation. Because maintenance is going to be super difficult, during the maintenance stage, the original developers usually leave the company. The company then hires new people to maintain the product. If you go to Google and just type coding memes, you may laugh at first, but those are actually true stories no matter how fake they seem. Once the people are tired of pulling their hair out to solve problems they leave and the process starts all over again.

In conclusion, we have learned a lot today about project planning. It might have been an information overload so you may need to read the article a couple of times to understand. In the next article, we will be focusing on "the how" portion of the Spring Planning, and why a simple task may seem more complex than it is, in particular, it is all because of the database.

Last Updated: 02/03/2022