Is all work related to a sprint meant to be conducted within that sprint, including pre-work?
We have a multi-disciplinary team consisting of 4 developers, 1 designer, 1 business analyst, 2 testers.
When running a sprint (typically 2 weeks for us) there are activities that need be completed prior to some tasks able to be started. For example:
- Task business requirements
- API interfaces require implementation specification
- Writing test plans
- User research for a feature
- User interface designs completed so they can move to development
If the scrum team should be working on a common goal for a sprint how do all of the above fit and align during a sprint?
For example, let's say the goal is "A user can save products to their wish list", how are the following addressed as a scrum team? (not an exhaustive list, but representative of the problem):
- Assuming this feature has arisen from user feedback, should further user testing of the new solution be performed in the same sprint? (then what about user recruitment?)
- Visual designs or components are needed for front end developers to implement, but the designer needs time to create these first. Should designs have been created a sprint before?
- When does a tester have all the information to define and execute a test plan and strategy for the feature?
- At what point are business requirements captured and refined? Prior to backlog grooming or sprint planning sounds reasonable, but then isn't the analyst working "ahead" of others, therefore not contributing to the current sprint goal?
Seems to me like we need two teams or multiple goals so that each team member is contributing in a meaningful way with their core skills and can assist with other team members as needed (i.e. spike). Is a "design team" or "design sprint" separate from a "software development team" a common approach?
Having developers assist with user research is valuable but doing so for a whole sprint seems to only deskill them or not engage them for what they are hired for and passionate about. Likewise, it would be unfair to place a visual designer in a scenario where they are involved with IT infrastructure. Not to mention associated operational and staff costs.
I'm not sure what, exactly, some of these activities mean to you. For example, it's not clear what "task business requirements" or implementation specifications for API interfaces mean or why they aren't part of the associated Product Backlog Items. These may have specific connotations for you that I'm not aware of, but I can speak in generalities.
If you are using Scrum, there is always a Sprint happening, so all work is done within a Sprint. However, there are typically two types of work happening. The first is the design and development done to make progress toward the Sprint Goal and defined by the work in the Sprint Backlog. The second is Product Backlog Refinement. Work such as making sure the Product Backlog Items are clear and understood, user research, sufficient user interface designs, and even more technical work like system architecture definition, can all be grouped under Product Backlog Refinement.
When planning a Sprint, you should consider the amount of effort needed to perform refinement. Prior to the November 2020 Scrum Guide, there was a recommendation that approximately 10% of the Sprint's capacity would be dedicated to refinement. This recommendation was removed, probably because it was deemed too prescriptive. Some teams were forcing themselves to spend 10% of their time on refinement. Other teams timeboxed refinement to 10% of their capacity even if they needed more. The team should look at their Product Backlog and understand how much is well-refined and ready for selection in a Sprint and dedicate the right amount of time to refine work to have just enough of the backlog refined.
Depending on the strengths and specialties of the people on the team, they may spend different amounts of time doing the development work versus the refinement work. I've found that some people are more closely aligned with the Product Owner and refining the Product Backlog than executing the detailed design and development in the Sprint. UX researchers, UX designers, business analysts, and product managers all fall into this category. This doesn't mean that they aren't supporting the people developing toward the Sprint Goal or contributing to getting Product, but that their primary attention may be on getting the work in the Product Backlog into a state that is ready for a future Sprint.
Depending on the size of your organization, there may be opportunities to experiment with design sprints or dual-track methods, but it doesn't seem like your organization is large enough to support that structure at this point. However, you can see what practices have worked for others, and perhaps you can find more information about incorporating these techniques into smaller teams and organizations.
Is all work related to a sprint meant to be conducted within that sprint, including pre-work?
No, if that was the case then no work would be refined and made Ready for Sprint Planning.