Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

best practice for organising backlog stories yet to developed

Hello guys,

i'm wondering what is the best practice for organizing the backlog. currently i'm working on a a big project with many epics and hundreds of user stories. the backlog is bit messy, and the team is unsure which user story will be developed for which sprint.

as far as I understand in the agile framework, we should have releases, and those epics/user stories should be organised by the release, which we are currently trying to achieve. however, my team has strong desire to have a low-level user story assigned to which future sprints! 

here is the thing, our design team usualy is ahead of our development team -duh- so they express wishes to know in advance what tasks or user stories in the few upcoming sprints to start working on rather than waiting around till the development team is ready for sprint planning session. the thing is agile adapts as it goes rather than have such clarity of vision in the few months to come (more like a waterfall) 

what do you guys think?

I feel like we should not create few sprints in advance since the sprint planning should be the whole team efforts and commitment for the sprint which cant be figured unless the team is ready to commit to it. and as far as organising things per releases, we have a good 8 months between each release so that's too long of a chunk to organise :!

appreciate your inputs 

1 comment

Good afternoon Mr. Alhamdi,

Good question! Best practices suggest that the Backlog should be an environment where Epics can be developed in more detail. Column headers like Why/Objective, Goals/Requirements, Prioritization, Dependancies, Business Value and the like can then be presented to various teams (Design, QA/C, Engineering, Infrastructure, Release Management, PMO or whoever) that will/can contribute or be affected by the those Backlog items listed.

Secondly, teams then give a preliminary review of the Backlog Items (t-shirting of a sort) looking for risks that may affect their efforts specific to those deliverables. After this step is completed then the items can be ready for Iteration/Sprint Planning by the teams.

Also at this point the various development team(s) and the PO/Management can preliminarily  rank issues into a Releases and various teams can start creating Stories/Task to satisfy the requirement of each individual Epic.

By the way this is one of many, many approaches. This particular way ensures that no Epics or Stories reach teams before they are ready to be discussed.


I hope this is helpful.





Log in or Sign up to comment