Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

team scrum codes more than it can test

Last post 02:55 pm October 28, 2022 by Hugo Cruz da Silva Moraes Neto
3 replies
01:48 pm October 26, 2022

Good morning group.
You took on a new challenge in PO and our team is facing the following situation:

Team composition:

1 tech lead
4 devs
4 QA

we carry out the planning, doing planning poker, QAs and Devs participate. The sprint is estimated according to the testing capacity, the devs end up working on new cards to take advantage of the time and not be idle.

When the sprint ends, I always have a large balance of user stories to test, and I move them to the next sprint. This ends up generating a backlog, which will compromise the current sprint.

Any suggestions to better balance the team's work and work with a plan closer to reality, making the best use of everyone's time?


04:35 pm October 26, 2022

The sprint is estimated according to the testing capacity, the devs end up working on new cards to take advantage of the time and not be idle.

Taking on new work is the last thing the Developers should do. They've already got work in progress, untested, and their commitment is to create an increment that is Done. If testing is needed then, as a matter of professional commitment, they will do whatever it takes to assist with that.

When the sprint ends, I always have a large balance of user stories to test, and I move them to the next sprint. This ends up generating a backlog, which will compromise the current sprint.

No, it's worse than that. You've eroded the Sprint boundary and removed transparency over the undone work, which ought to be accounted for on the Product Backlog, as well as over the failure of the Developers to make and honor a shared commitment.


11:17 am October 27, 2022

 

The problem is that you are starting work instead of finishing it. Instead of figuring out what the developer can do to help get work fully complete, they are starting new work and creating an inventory. Inventories are waste. In addition, they could be building this new work on top of untested (incomplete) work that may not yet be stable, so this could be done at risk of not-insignificant rework.

Along these same lines, hand-offs are waste. When you take a unit of work and hand it off from a developer to a tester, you also need to convey information in addition to the work product. You could do this up-front, by also handing over relevant documentation or you could do this just-in-time by answering questions or addressing concerns as they come up. Either way, though, you need to invest time in making sure that all the people involved in getting work done have the same understanding.

You're in an interesting position where you have an equal number of developers and testers. Most organizations that I've seen have far fewer test specialists than developers on a team. Having equal numbers can open the possibility of pairing. For each unit of work, one developer and one tester work together from start to finish to understand the requirement, making sure that it's a high-quality requirement (complete, consistent, unambiguous, testable), talking through the design and implementation to understand how it satisfies the requirement, and then testing the solution as it is developed to build quality in.

You may also want to prepare your organization to scale. You may find that it's not possible or desired to support an equal number of development specialists and test specialists. Having the test specialists teach basic-to-intermediate testing skills to the developers can allow a single developer to take a unit of work from start to finish. The test specialists can support the most complex cases while continuing to build test-related skills among the developers.

Regardless of the approach that you take, if you start thinking about how much time or effort it will take for the team to finish the work, you'll probably start seeing better Sprint Planning events that let you more accurately forecast the work needed to achieve the Sprint Goal.


10:35 am October 28, 2022

Goog morning guys, thanths for your help, i will check with my team yours propositions.


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.