How to eliminate burnout?
A recent survey shows 57% of Tech Workers are burn out by work. Likewise, there are several independent surveys been carried out which depicts the misfortunate part of tech life A major contributor to the burnout involves wrong estimation and deadline. There are other parameters also involved which compromise of Office Politics, Repetitive work for a long time, Appraisal, etc. Let's keep aside the other parameter and talk around the major contributor of burnout I.e. Wrong estimation and Deadline.
It often happens a non-technical person say for example a Non-Technical Manager or Scrum Master or BA or Sales Team without having visibility around the actual work propose a ballpark estimate to the client. Often there is a situation where a client does the auction for the project. Hence IT giants in order to get the project give less estimate. Once companies get the project and execution for the same gets started then the member of the team who executes the project is exposed to a tight deadline and hence suffers from burnout. Which intern impacts their mental health and life.
From business standpoint getting client holds the highest priority. But a general thought which keeps on bugging me from time to time is "because of management why should an employee suffer?".
Ideally, before giving the ballpark estimate to the client, a realistic estimate should be collected from engineers who would do the work. There are different ways of coming up with an unbiased realistic estimate.
Some of the popular technique is
Planning Poker:
This is one of the effective ways of coming up with the estimate for a story. It’s been religiously followed by a team which truly works in Agile methodology. Each member of the team is highly involved in the estimation process. Getting everybody in the team involved in the estimation process is critical to come up with an accurate estimate. Planning poker is a game that team members play during Sprint Planning meetings to ensure that everybody is contributing and his or her point of view is considered during estimation. It starts with one of the team member(#Moderator) reading the story/requirement, and giving high-level info around the ticket.
The team focuses majorly on WHAT part instead of HOW part.
To starts with each team member is given a set of cards or sticky notes with a number on them. This number represents story point, ideal days, hours or any other units in which team estimate. It is suggested to use Fibonacci but it is not necessary, one can use a specific sequence which may suit for a team. Our team used sticky notes having hours written that would be needed for the story.sub-task, starting 0.50h, 1h, 2h, 4h and so on. It worked for our team. Once the high-level requirement is read aloud and a team has the visibility around “What” needs to be implemented then starts the game. Team members are requested to pick up the card with the number written on it. Initially estimates from members to members can vary a lot as a result estimates can be present all over the graph. Once all the members have voted, members having highest and lowest estimates explains their understanding behind coming up with their estimates. The expert having detailed knowledge about the implementation part can point out the hurdles which team might face while implementing the story.
Above discussion among the members brings up the clear picture around the requirement. Post discussion based on everybody agreement Scrum master concludes the discussion and assign a story point to the task. Through this process, members of the teams have clear visibility around the parameter list that needs to be considered while giving the estimation.
T-Shirt Sizes:
This mode of estimation is quite popular this day within an Agile team. At times, it becomes difficult to estimate a large backlog having relatively large items. Especially when multiple scrum teams work on the same product. Stories are estimated on the basics of t-shirt sizes: XS, S, M, L & XL. Like Planning poker, a Moderator reads the story and team focuses of What part. Post understanding What needs to be implemented team comes up with a size written on the card based on their understanding. Similar to Planning Poker, members of the team collaborate among themselves and come up with a mutually agreed estimate.
In addition to the above workflow T-shirt scales also demands extra effort on the part of the person coordinating the agile process. Since sizes cannot be put on the story, hence sizes need to be converted to numerical values for the sake of tracking effort over time and charting an estimated velocity for the team.
Bringing it all together
By using the above estimation techniques, we can come up with an achievable estimate and can accordingly communicate the same to the client.
However, from the business standpoint, in order to get the project from the client, we can propose a different figure to them (like it's been carried out currently which I feel is wrong). Since we have clear visibility around the estimate, so we can add the buffer resources who will be contributing for successfully delivering the project.
Hence by coming up with a realistic estimation with the help of different estimation techniques and proper planning, burnout can be minimized.
Please share your thoughts in the comment section, we can connect on LinkedIn and talk more. If you enjoyed this post, I’d be very grateful if you’d help it spread it to your connections on LinkedIn or other channels.
Thanks!!