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

best practice for organising backlog stories yet to developed

Ahmed Alghamdi July 4, 2017

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


Log in or Sign up to comment
Daniel Eayrs July 10, 2017

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.




AUG Leaders

Atlassian Community Events