Back to Forum

thoughts and improvements regarding "real life problems of scrum"

Last post 06:14 pm November 10, 2020 by Sebastian Synoradzki
2 replies
Rotem Shaul
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  

 

Ian Mitchell
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?

Sebastian Synoradzki
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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.