The Importance of Project Planing and Scrum

Home / Blog / The Importance of Project Planing and Scrum


7min. read

The Importance of Project Planing and Scrum

After the long working day, you want to commit and push your code before leaving the office, right? You call it the day. Then, the next day you come back and you saw someone else pushed the code in the middle of the night, and merged it to master, and deployed to the production server, and the change gave you the nightmare: conflicts everywhere!

That is the real nightmare, right? And when there are conflicts, you not only need to merge them, fix them, you also need to do all the test to make sure that your own functionalities are still working (unit test), and the new features survive the merge (integration-test), and the old features are fine (regression testing). That is a lot of things to do!

How to prevent conflicts?

That is the BIG question. Believe it or not, I heard someone leading the tech team said it is unavoidable. It is actually avoidable! If you heard about Agile or Kanban, you should know already. But if you don’t, here is the thing for you.

Conflicts are the same piece of code that two people made at the same time, to the different branches, and eventually got merged into the same branch and no one knows which one is the right piece of code to use in the merged branch.

Actually, agile and kanban were designed to prevent conflicts. With the project planning process at the beginning of the sprint (for agile) or the day (for kanban), we can limit the number of projects to do and we can only pick the projects that are NOT closely related to each other.

Hence, if you are the team leader, scrum master, project leader, product owner, or whatever, and you cannot prevent the conflicts, you suck!

Prevent Overwhelming Situation At Work

The two methodologies mentioned above, agile and kanban, are not only used to prevent conflicts, they are actually mainly used to prevent OT. During the sprint planning meeting, the scrum master must know the number of man-hours in the sprint (exclude daily scrum, meeting time, buffers for code review, code change, integration testing, regression testing, deployment, some bugs fixed, and urgent critical issues). For example, for the 2-week sprint, with 9 working days (minus public holiday), and 5 people (minus 1 person taking maternity leave for the whole sprint) - each day has 8 hours - and each sprint has the buffer of 10 hours per person - This sprint will have 8 hours times 9 days minus 10 buffer hours, and then times 5 people, = 310 man-hours.

Normally all tasks must be in the backlog, the scrum master must pick the unrelated tasks (to prevent conflicts) from the backlog, sorted by priority and deadline (lower priority with deadline could be picked, too), and the sum of the estimated hours of each selected task must not exceed 310 man-hours for this sprint (to prevent OT).

Then, all these selected tasks must be placed in the TODO list, to be assigned to the team members. And because each member has 62 hours in the sprint, the tasks assigned from the TODO must not exceed this number, too.

So, you can see that we can now prevent the two big problems in the organization already.

Who Created The Tasks

The product owner talks to the business people, clients, customers, users, etc, and summarizes everything to create the tasks. In a small team, probably just let the scrum master does the job.

And to be fair, the agenda of the planning meeting should include the time to talk about the new tasks so everyone is on the same page. Of course, the new tasks have no estimates. We can also use the poker cards for this (it is the set of cards used by the team, each card contains the number of score/hours so the team member can use to estimate the hours required for the task). The numbers gotten from the team members can be averaged and put as the estimate of the task.

For example, the senior member gives a task 2 hours, but the junior and fresh grad, give 7 and 13 hours. The estimate should be 22/3 = around 7 hours.  If the task is assigned to the senior member, then he should finish it fast and utilize the leftover time for something more useful. If the task is assigned to the junior member, then the senior should spend more time helping to train the junior member and make sure everyone in the team pick up the speed.

The task can never be estimated by anyone outside the team because they never know how complex the task could be. And even the team members themselves, sometimes they also need to do some research before coming back with the more accurate number. It is rude to me if the people outside the team expect the team yo finish something in their own timeline without considering the real complexity of the project.

How About the Critical Problems

As indicated above, the urgent critical issues are included in the buffered hours, so we just deduct the time from these 10 hours per member. Hopefully, this amount of time is enough. Depending on the nature of bugs and issues, there are no magic numbers, other organizations may set it to 15 hours or 20 hours per sprint.

Do you see? With these urgent tasks, we still see no need to work overtime.

In Real Life

Many organizations feel that it is hard to do the scrum planning thing. I saw some organizations implemented it but discontinued. The remnants of scrum could be found everywhere. This is very difficult for people who are unwilling to manage. With scrum, everything must be planned ahead, at least we need to give the tech team 1 sprint to finish one task. When there are more urgent tasks (and mostly urgent because some people did not concern about the deadline or the delay in decision making), the buffer will never be enough. Hence, the whole scrum fails.

And when it fails, OT and conflicts cannot be prevented, hence the tech team could suffer from these undesired situations. Anyway, what I heard from someone outside of the tech team was that: no one else is going to care, it’s not their problems after all. It’s the tech team’s problem! I want to work this way, give them urgent tasks, I don’t care. I’m comfortable this way. If there are bugs, the tech team can fix it anyway. And if there are bugs, the tech team could fail to meet KPIs, less salary increment, save the company’s money.

I hope that this is not your organization. A long time ago, I resigned because the boss said that IT is a liability (I could not remember the exact word). And moreover, when I resigned she wondered why did I need to pay taxes because IT people should not get that high salary! (In Singapore, you have to earn more than $20,000 a year, then you have to pay a 2% tax for the amount exceeding the first $20,000.)

And do you see how unfair it is? When anyone submits the ticket to the customer service team, there is always a response somehow informing you that the team will get back to you within some amount of time. Some of the systems or websites even have the message informing the customers that the team could need an average of 2 hours to respond during the working hours. And some processes, such as getting something fixed or claiming the spare parts for the broken ones, could take much longer, despite the fact that you know very well how long getting the parts shipped out or fixing the things could be. There is always the queue that people need to line up and wait for things to be done given the limited resources and time. Any other departments could set up all these things, but for the tech team, when we are trying to set up, please understand and cooperate.

We, the tech team, did not graduate from Hogwarts or Mahoutokoro or Ilvermony or Beauxbatons, we are muggles, no-majs, not wizards. We cannot just cast the spell and deliver what you want.

Category: Tech Tags: scrum, planning, management

English | ภาษาไทย © 2020 Ratinan "Nat" Lee · All Rights Reserved | Log in