How to use Cubyts for Sprint Planning?

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