What should my team members do if they cannot complete work on time and are unwilling to work overtime?

In an agile development team, there is a phenomenon that has existed for a long time: Procrastination. Developers or team members stay idle in the early stages of development, and cannot complete the work in the later stage.

 

Scrum Master Lisa found that, in a 5-person development team, the user stories are divided into 4. Each development completes a user story, which leads to all of them being delivered together in the later stage.

 

Moreover, the developer basically does not spend much time writing acceptance criteria before receiving testable user stories, and the acceptance criteria are not written in enough detail, and it only highlightes modules and functions that should be tested.

 

If you encounter this situation, what would you do?

 

1. Improve the sprint process, starting from sprint planning and daily scrum. Testing should be closely coordinated with PO, UI, and development to fully understand the requirements. Acceptance criteria should be written early and continue to improve throughout the sprint. User story writing may also need to be improved, so that good stories can be tested. Testing modules and functions alone may not be enough.

 

2. Another reason for insufficient testing is that the plan is too demanding, the allocated testing time is insufficient, and the Definition of Done (DoD) is not taken seriously (assuming that testing completion is one of the definitions).

 

3. Increase the coverage of automated testing methods to improve the overall testing efficiency.

 

4. The retrospective should focus on this issue.

 

The story card of the PO may be too large. It should be divided by function, written according to customer value, and divided into multiple stories.

 

Developers and testers are both members of an agile team. The relationship between the two should be equal.

 

The developer and tester should participate in the review together, and after reaching a consensus, start the work, and lastly, leave some time for testing.

Analyze the problem first:

1. User stories are completed in the later stage of development, the completion time is late, and the testing time is not sufficient.

2. The work in the early stage of the test is not detailed enough.

 

Ideas to solve:

1. The Definition of Done requires analysis, test design, and user case writing in the early stage. The DoD needs to be clear, unambiguous and approved by the team.

2. Story splitting and sprint planning need adjustments. Explore the possibility that stories can be submitted in stages rather than all at once at the end of the sprint.

 

This situation should be the current status of development and testing. When there is no automated testing or when testers can only do functional verification testing, then testing can only be performed after development is complete.

First of all, there is a problem in the statement itself: “ the tester can’t complete the testing”. Because in Scrum, we emphasize the team itself. So, if the testing cannot be completed, it is not the tester but rather the team that failed to deliver on time. From the team's point of view, it is everyone's responsibility to finish it. The blame should not fall solely on the tester.

 

What if the test cannot be delivered at the end?

 

Through our analysis, we find that the original test is too heavy in the early and end stage of the development work. What's the reason?

 

1. First of all, let’s observe if the user stories are too big. For this case, “the user stories are divided into 4, and one development is a user story”, which implies that four people each make their own stories. To solve this, you can use the method of managing WIP, for example, two or three people should start working on the first user story, while the rest of the team works on the second story. So the testing process can start as soon as the first story is completed.

 

2. Find a way to be better prepared at the earlier stage of development. The test should be detailed and accurate so the data can be useful at the later stages of development.

 

To sum up, we would like to emphasize that it is the responsibility of the team. When we raise this problem in the retrospective meeting we should think of a solution together. These suggestions should be raised by the Scrum Master for the team to discuss together, it is not for the Scrum Master to instruct the team to do and follow.