best practice for organising backlog stories yet to developed

[Ahmed Alghamdi]

Hello 

sorry for the long question!

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 

[Peter T]

Couple of points from me.

1. You may have 4-5-6 as many sprints created as you want.
2. You may assign stories to the sprints - this does not mean a lot, the final list will be refined during sprint planing.
3. If anyone on the team - developer or designer needs to work on a story in a sprint - that means that the Story should be in the sprint.
4. If your designers work ahead of the dev team that means these stories will be in progress , and not completed during the sprint - which is not ideal. Think about breaking the story into design and implementation part.
5. If you have a lot of stories breakdown you can use Structure to create and maintain the hierarchy.
6. If you need a Release Management Solution to track the execution - Milestones and Approvals for example you can use Cycle Control.

[Nicolas Seronvalle]

Hi,

From my experience here is what worked well with many software development teams. The main point is to be organized, have a high-level planning before you begin, refine it and adapt it continuously.

Before beginning the work on your version it's usefull to have a high-level vision: wich epics/stories must, should, could be done (and what's out of scope). Then your team can organize the backlog : prioritize the issues, document it, analyze it, ask questions, ... The goal is to make sure everyone understand what needs to be done and why. So in Jira you put the most important issues on top of the backlog. Once backlog is organized, once you know enough things to do the work on the first issues (your team already knows a bit about how they will do things) you are ready to have a version planning session with your team. 

There it's good to fill out the sprints. Give story points or whatever to get visibility on how many issues you will be able to deliver with the required quality on the release date. Of course during the various sprint plannings you will need to adapt your plan based on feedback and circumstancies: change priorities, refine epics/stories and so on. But having a high-level vision of your future sprints is important to organize your work and manage dependencies.

During this process keep as much as possible the impacted teams (design) and the customers involved. 

Then you're ready to launch your first sprint planning and your first sprint. Your design team can already worked on what has been prioritized during for the future sprint, knowing that things can change (but will still stick with your main goal/objective/vision for this version).