scrum, sprint and testing process
Not sure if this is the right group to talk/ask about Scrum thing.
Question is :
We have a product where in we have different group of engineers working for UI, model, Backend, accessibility etc. Issue is each group is working independently (in a sense of there is dependency they mock the data) and do development.
Now for each group we need to assign tested Or a person who can look after test scenario etc.
But each group is working independently. So if “Feature 1” is being developed and all the teams are working for this “Feature 1”, then UI scrum team have tester which is doing UI validation, Backend scrum team have tester who is doing API verification. And all this is happening at different sprints. I mean UI team may develop UI by sprint 2, but then Backend scrum team may have backend/API developed for same Feature 1 in Sprint 4.
So if you see individual components are verified, but still it is not deliverable, as final integration/E2E testing is not done.
So my question is :
- After all being developed do we need a separate sprint just for integration testing?
- OR how can we do final verification before release?
- OR do we need to change the scrum process, reason being we have complex product which need all components to be developed and it takes time. So UI can be ready today but API’s are not. Similalry there can be more factors like accessibility, auth etc which can take more time. So how can we plan sprints, scrum team so that component testing as well as integration/E2E testing all can be covered before release?
Any one have any experience in planning scrums for large products?
If you were to organize into cross-functional teams, a good portion of this problem would be resolved.
Instead of requiring "Feature 1" to need multiple teams to complete, ensuring that each team has all of the necessary skills and allowing a single team to take "Feature 1" from concept through integration and delivery would reduce, if not eliminate, the hand-offs. Then, you wouldn't need to worry about scheduling the integration testing or final verification because the team would be able to do that as they complete and integrate the work.
Although there are cases where platform teams or complicated subsystem teams make sense, the general recommendation has been to align teams with value streams or end-to-end functions and slicing changes such that the team can complete valuable, end-to-end work each Sprint. Even if the change can't be done in one Sprint, the team can maintain the integrity of the Increment.
Thinking about your organizational structure will probably have much better results than looking at your process or tying to solve scheduling problems.
Have people chosen to self-organize along the lines you describe, or does it just reflect present organizational constraints and thinking?
Scrum is very good at highlighting structural impediments quickly, and the pressure will be on you, and the team, to change Scrum rather than the company itself. There's an organizational gravity to be overcome. If you give in to that pressure, any "agile change" will be molded to the organisation's current form and shape, and the expected improvement in outcomes will not be achieved.
So how would the people you mention choose to self-organize around the work at hand? Are they empowered to do so...and is self-organization a skill they may have to be further encouraged to learn?
I agree with @Thomas. You describe a process that is very waterfall-like. I visualize a Gantt chart with mutiple bars running simultaneous and then arrows protruding from the end of each into a 5th bar that is marked as Integration Test. What you are creating is a gate to production that every "feature" has to go through. It makes me wonder what happens if the backend team makes a change that would impact the already completed UI? Also wonder what the UI team would be doing if they have already completed their work on "feature A"?
You may be using terms from the Scrum framework but it does not seem that you are actually using the framework. In Scrum there is a team of self-managed, self-organizing cross functional individuals that are focused on delivering value every Sprint. An Increment is delivered every Sprint and the increment must be usable.
I suggest that you read the Scrum Guide (https://scrumguides.org/index.html) to gain a better understanding of the framework. Then as @Thomas suggests, focus more on the organizational structure that will make you successful. The process will follow along as you organize to be more agile.
Thank you all. Appreciate for giving guidence.
I will go through the guide and will propose / talk to mgmt for the same.