thoughts and improvements regarding "real life problems of scrum"

Last post 06:14 pm November 10, 2020
by Sebastian Synoradzki
2 replies
Author
Messages
02:10 pm November 5, 2020

Hi Everyone
I would like to get some help regarding "real life problems of scrum".
I am working as business operations project manager nowadays and i got an opportunity to join other organization as R&D project manager / Scrum master.
I got 2 theoretical questions and I would like to get some help. 

1. If I have a situation that in the last several sprints, Developer A burned significantly more points than any other team member.

   A. Which parameters will you use to identify the reason for this exceeded performance, based on JIRA’s capabilities.
   Please leave the point  that Story Points are not suitable for measuring the performance of an individual. They are used for sizing and capacity planning.
   I am not that familiar with JIRA’s capabilities.

   B. which methods (quantitative or qualitative)  will will apply outside of JIRA (or another tech tool) to identify the reason for this exceeded performance.

2. QA has many of tickets in each sprint that appear as “Ready for testing”. Some of them are indeed ready, while others - not at all. 

A. Share your thoughts - what can be the possible reasons for tasks to appear in the workflow as ready for QA, when they are actually not? 
     I was able to think about 2 reasons:
     1. Configurations & Workflow: 
     2. The team's definition of done: It is important to have an agreement with the team on the Definition of Ready and the Definition of Done

      Can you think about 3 more reasons for that?

B.    You have been asked by the QA team lead to find a way for his team to recognize and sort out tasks that are not ready. The tool of task management for all teams is JIRA. What could be a possible solution (or solutions?). 

   I though about board configuration as there may be several statuses in the QA column.
   Adding news phases in the flow in order to reflect the current status Ready for Dev" => “In Development” => “Code Review Requested” => “In Code review” =>       “Ready for Testing” => “In Testing” => Done  
 

07:15 pm November 5, 2020

If I have a situation that in the last several sprints, Developer A burned significantly more points than any other team member.

I'd suggest that, if the team was jointly accountable for the completion of work, it would be neither possible nor meaningful to gauge individual burn rates at all. Are the team satisfied that each member is suitably productive?

QA has many of tickets in each sprint that appear as “Ready for testing”. Some of them are indeed ready, while others - not at all. 

How explicit is the team's policy for determining whether or not work is ready for test?

01:36 pm November 10, 2020

If I have a situation that in the last several sprints, Developer A burned significantly more points than any other team member.

-> A: None, if answer B´s action does not clarify, i´d rather observe more carefully over a couple of sprints to find out.

-> B: A conversation. As a scrum master i want to know. I would want to have a team conversation on this and learn the causes.

 

QA has many of tickets in each sprint that appear as “Ready for testing”. Some of them are indeed ready, while others - not at all. 

-> A: Personally i think guessing reasons doesnt help, i wouldnt do it.

-> B: Again, personally, i would bring DEVs and QA (not sure if optimal scrum setup) into a conversation to collaboratively work on a solution. I would ask a lot of goal focused questions to help find a solution. I wouldnt suggest anything.