Learn how to leverage Cubyts to streamline your sprint planning sessions. This article provides the adoption journey for a variety of users, tips for aligning your sprint planning sessions with your broader platform goals. and a checklist of key questions, practical guidance for using the platform.
How can you align your sprint planning sessions with the broader platform adoption goals?
Is the team planning their work well?
Unused design handoffs flag, Poor quality designs flag, Overlapping requirements flag
Are the resources productive and well utilized?
Overloaded team members flag
How is the quality of the product (designs, requirements, code and test cases)?
Test cases missing flag, Benchmark tasks missing flag
Are there release risks with the product?
Benchmark tasks missing, Poor quality designs
Planning aids to help with our goals:
Team reports, Delivery reports, Feature branch/PR reports
During the sprint planning sessions, you can use Cubyts for the following;
To create the sprint plan/aid your backlog:
Check ‘feedback’ category flags
Check Flag: ‘aging items’ in the backlog
Check Flag: ‘Unused design files’ in backlog
Check the effort category flags for currently active sprints
To find loopholes in the already planned sprints:
Filter flags by planned sprints
Add ‘planning sprints’ in independent flag configuration wherever possible
To preempt planning flags in advance
Set a rule to add effort estimates, assign tasks, and members against the identified issues
Misc. questions and places to find answers on the platform:
The Scrum team can review the flags and reports on Cubyts before a sprint planning session to get answers to the suggested questions. This will ensure that the sprints are planned well and the right bottlenecks are discovered well in time.
Are there requirements ready to be picked up (waiting in queue)?
Are there requirements that can't be picked up right now?
Are there duplicate requirements?
Are the right resources available for the stories to be picked up?
Are the test cases ready before the development starts? Developers should know what is expected.
Are the stories technically well laid out? Are the tasks defined well? Can the developers start the development without any ambiguities?
Are there unfinished stories we need to prioritize? Are there stories which are jumping sprints which we need to prioritize first?
What’s the overall status of my features? How are my features progressing?
How did my previous sprints go?
How is my team performing? How well are they utilized?
Using Cubyts to answer the questions above.
The following sources can be used on Cubyts by the Scrum Team to determine the answers to the questions asked in the section above:
Unused designs hand-offs flag
Design handoffs below quality levels flag
Overlapping requirements in design issues flag
Overloaded members flag, Team performance chart
Test cases missing flag
Tasks planned not meeting benchmarks flag
Issue extended beyond sprint
Feature progress
Sprints status
Team summary/ Team performance dashboard/PR summary
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article