How To Eliminate Burnout And Make Agile Teams More Productive

Read it in 4 Mins

Last updated on
31st May, 2022
Published
29th Aug, 2018
Views
1,134
How To Eliminate Burnout And Make Agile Teams More Productive

A recent survey shows 57% of Tech Workers are burned out by work. Likewise, there are several independent surveys been carried out which depicts the unfortunate part of tech life. A major contributor to the burnout involves wrong estimation and deadline. There are other parameters also involved which comprise of Office Politics, Repetitive work for a long time, Appraisal, etc. Let's keep aside the other parameters and talk around the major contributors of burnout which are-

  • Wrong estimation, and
  • Deadline.

Burnout And Make Agile Teams
It often happens that 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 proposes 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. This, in turn, impacts their mental health and life.
Burnout
From a business standpoint, getting clients holds the highest priority. But a general thought which keeps on bugging me from time to time is "why should an employee suffer because of management?".

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 techniques are outlined below.

Planning Poker:

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: For a simple Sprint and easy Estimates

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 the WHAT part instead of the HOW part.

To start 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.

The fun way for Agile teams to guide sprint planning

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, and as a result, estimates can be present all over the graph. Once all the members have voted, members having highest and lowest estimates explain their understanding behind coming up with their estimates. The expert having detailed knowledge about the implementation part can point out the hurdles which the 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’s agreement, the Scrum master concludes the discussion and assigns 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:
Different sizes
This mode of estimation is quite popular these days 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 scale 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.

Bringing all together
However, from the business point of view, to get the project from the client, we can propose a different figure to them (like it been carried out currently which I feel is wrong). As we have a clear visibility around the estimate, so we can add the buffer resources that will be required for successfully delivering the project.Hence coming up with a realistic estimation with the help of different estimation techniques and proper planning will result in minimizing the burnout of team members and help them live a happy life.
Employee burnout
Please share your thoughts in the comment section, we can connect on LinkedIn and talk more. If you enjoyed this post, spread it to your connections on LinkedIn or other channels.

Thanks!!

Tags

Profile

Suraj Sharma

Blog Author

Suraj Sharma is working as a Full Stack QA Engineer with leading IT farm and is striving for bringing change in Industry. Strong believer of "Learning or Decaying" mantra. Technology explorer, Blogger and part-time cyclist by passion. Connect with him on LinkedIn.