Ideal vs. real: sprint capacity management

I encourage the Scrum Team to try to vertically slice Product Backlog Items thinner so they can be developed and validated earlier in the Sprint.

I also see QA people helping refine acceptance criteria, pairing during development, or reviewing unit tests. Even a little cross-skilling helps balance workload and builds empathy. Developers helping with test automation, test data setup, or exploratory testing could also be something to consider.

If that's not possible, "open" time might be an opportunity to invest in the team's future effectiveness. Continuous improvement from past Sprint Retrospective action items, mentoring, and innovation might be things to work on.

Ah, the cult of efficiency. In the "downtime" people can do maintenance or R&D or education or whatever, maybe watch some funny memes. 

What's the goal? To deliver a working piece of something or to utilize resources? If the second then I guess that answers are rather obvious.

Each does their part to get the entire work item done

How would you describe their joint focus and commitment? Bear in mind that testers are Developers, since their labor and industry is needed to get work to Done.

Perhaps work-in-progress could be better limited, so Product Backlog items on the Sprint Backlog are completed earlier and more often. This could help smooth out starvation and bottlenecks in the workflow.

Although the decision to have strict isolation between people who develop and people who test, although common, isn't often a requirement, and the skill gap may not be large, especially for people who are involved in test automation. This isolation is called independence and comes in financial, managerial, and technical forms. The decision about what types and how much independence to have is a tradeoff decision that shouldn't be made lightly. Having cross-functional individuals capable of both developing and testing, allowing one or two people to collaborate through the entire life cycle of a work item, is possible.

It's often better to have these cross-functional individuals. However, we can assume that the organization is not ready or is somehow unable or unwilling to get to that. There are still things that can be done to minimize risks. The testing, verification or validation, doesn't need to wait for the end. Both groups should be involved in refinement to ensure they understand the work and what is expected and desired. Black box test development can happen parallel with development, and only white box test cases must wait for development to complete. During testing, developers can focus on improving developer (often unit and integration) tests, refactoring, and technical debt paydown. Depending on capacity, the testers can use the front part of the Sprint and the developers can use the back part of the Sprint for things like company-mandated training or personal learning and development.

Late to the party on this one but I wanted to chime in.  You have already gotten very good advice so this may be partly repeat.

I spent over 20 years doing software testing. I spent over 15 years doing software development.  Yes, those time overlapped.  Testers do not have to be limited to the "through the UI" testing that validates workflows within the product.  That is the type of testing that should be done minimally as anyone that is familiar with the "testing pyramid" will know.  So, the testers can do a lot of work in the early stages of the Sprint.  They can work to educate the coders on how to write effective unit and integration tests.  Helping them understand what is worth testing allows for faster feedback and helps to prevent defects.  The testers will also gain knowledge of what is being tested at the lower levels which allows them to target their later efforts so that they do not have to try and do "full regressions".  They can focus on what is being changed and limit the time it will take them. 

The testers can spend time doing some exploratory testing on individual coders' branches.  Run the product locally and explore. This can also help find defects sooner and provide valuable feedback.  It will also allow them to modify their own tests to meet the new functionality so that they will not need that time at the end of the Sprint.

The coders can spent time at the end of the Sprint helping the testers run their automation. Since they are in the "business" of writing code, they may be able to help the testers fine tune their automated scripts. It can also help the coders understand how the testers automation works. I've seen this lead to the coders introducing easier ways for the testers to access elements in the UI, which leads to more stable and reliable tests. 

Both groups can spend of the the "free" time reviewing the Product Backlog, working to better understand the items that are there and preparing them for future Sprints.  

There is a lot of work that coders and testers can do at any point of a development cycle. But they have to be allowed to do that kind of work. The people that "allow" them need to understand why it is important and support them in doing the work.

Great inputs Daniel. I will take the best practices from this conversation and implement in my team.