- General
-
Idées
+3
À l'étude
assign story to sprint from different backlog
I had to plan Sprints with input from different customers (customizations of one big product) so i want to setup an enviroment where different people can edit there own backlogs (and only there own backlogs) and i can take the userstorys from there and build a sprint with storys from different backlogs.
Solution
0
Solution
À l'étude
Matthew O'Riordan (Founder) il y a 13 ans
Hi Roger
As it stands, you cannot build sprints from other backlogs. Whilst I can certainly see a use case for this, this is quite niche functionality and would change the product quite significantly in that sprints will be divorced from backlogs. This would effect everything. What you can do however is let people work in their backlogs, and then move their stories to a central backlog when they are ready. This can be done by using the move theme feature (tool icon next to a theme). You could then allocate each user read access to the central backlog, and full access to their individual backlogs.
Do you think that would achieve the same result?
Solution
À l'étude
Hi Roger
As it stands, you cannot build sprints from other backlogs. Whilst I can certainly see a use case for this, this is quite niche functionality and would change the product quite significantly in that sprints will be divorced from backlogs. This would effect everything. What you can do however is let people work in their backlogs, and then move their stories to a central backlog when they are ready. This can be done by using the move theme feature (tool icon next to a theme). You could then allocate each user read access to the central backlog, and full access to their individual backlogs.
Do you think that would achieve the same result?
Hi Matthew,
thank you for your input, i think this works in general.
There are still Usecases where this is problematic because i had to do an Releaseplan and i cant plan anything from the other backlog until the userstory is really complete unless i use dummy userstories.
thank you for your input, i think this works in general.
There are still Usecases where this is problematic because i had to do an Releaseplan and i cant plan anything from the other backlog until the userstory is really complete unless i use dummy userstories.
Hi Matthew,
i tried it but it doesnt work very well.
Problem is i had to give the other user full access to the central backlog because with read only access the in target backlog i can't move themes there. To make this work i need a bit more possibilities from an right management point of view.
Even then its not very cool that i just can move whole themes and not single user storys (because in central backlog the themes are customer names and in customer backlogs they have "real" themes).
Another thing i had to check is if i can move the userstory back to the customers backlog when im done because its still in an completed sprint. This isnt a must have requirement but helps the customer project manager to keep track of his customer.
Seems like easy backlog is quite cool for a single product but doesnt work very well if you have more products handeled by a single team currently.
i tried it but it doesnt work very well.
Problem is i had to give the other user full access to the central backlog because with read only access the in target backlog i can't move themes there. To make this work i need a bit more possibilities from an right management point of view.
Even then its not very cool that i just can move whole themes and not single user storys (because in central backlog the themes are customer names and in customer backlogs they have "real" themes).
Another thing i had to check is if i can move the userstory back to the customers backlog when im done because its still in an completed sprint. This isnt a must have requirement but helps the customer project manager to keep track of his customer.
Seems like easy backlog is quite cool for a single product but doesnt work very well if you have more products handeled by a single team currently.
Hi Roger
It sounds like how you are trying to get easyBacklog to work really does not work well with what easyBacklog has been designed for. It has just not been designed to run centralised sprints across multiple backlogs, and that is really what you are trying to do.
Whilst the workaround solution of moving stories into the central backlog kind of works, this is not really a viable solution if you intend to move stories back into the user's backlogs as stories are locked into a backlog one you have assigned them to a sprint.
What we will do is think about how we could accomodate this need in the future, and figure out the cost and impact of this on other customers. I'll add it to our backlog, but until other people ask for similar functionality, this will unfortunately remain low down on our backlog priorities. I hope you can understand that we need to focus on building out the product features that most people are asking for and need. I am sorry in this case we don't have an immediate solution.
Matt
Roger, been giving this a bit more thought and allowing users to add stories from other backlogs to a sprint really does introduce a whole plethora of problems for us.
- When a story is assigned to a sprint it becomes locked. As such, we would need to manage locking of stories between backlogs, and stop users from reassigning stories to multiple backlogs.
- Total project story points would now be variable based on the stories you have in your backlog and in your sprints. As it stands now, burn up charts and burn down charts are based on story points in the current backlog over time. Allowing users to add stories outside of the backlog would mean the effective overall story points would increase yet the backlog would not show this.
- One of our key features is backlog snapshots so you can compare the state of a backlog at particular points in time. If we allowed stories from other backlogs to be part of this backlog's sprints, then would we show that in the snapshots? It would seem silly to because they're not really part of this backlog, yet they are effecting the points to complete.
So my thinking about this is why don't you just use one big backlog across all your products as this would allow you to build sprints from any story in any theme?
Or, alternatively, would it be useful instead to simply allow you to import stories / themes from other backlogs (not move, make a carbon copy), and add them to the current backlog? That way you could give product owners read only access to the overall backlog so they can see their stories and when/if they are assigned to sprints, but let them build up their own backlogs that you can import from.
Finally, another alternative may be instead to simply run separate sprints for each product as each product should really be tracking it's own burn down / burn up, and progress. Whilst I appreciate your teams may operate as one, for each week you can assign the expected velocity of the team on that project, and you could simply manage effort allocations for each externally with a spreadsheet so that you know your team is for example spending 10% of their time on product A, 20% on product B, and the remainder on product C. That way each product is managed as it should be, as a single product, and all reporting will be accurate. Assuming that approach would work, would you not then possibly just need a centralised reporting facility so that you can see progress across all projects (something we are considering now anyway)?
Would be great to get your thoughts on this.
Matt
Matt
Hi Matthew,
understood the problems i think of a much simpler solution now. Because there are not many products, its a single product with customizations for different customers the solution with different backlogs isnt very usefull. The single projects/customer specific things are just too small to handle it as a full product. I also had to plan single user storys from different customers into an sprint (sometimes bugfixing sometimes really small changes). Running Sprints for Customer A and then for Customer B is the goal i want to achieve but in the real world i always have TODOs from other customers, especially when there are really small changes.
Copying User Storys is also not a good idea, because thats a copy and if there are changes i had to do the changes on 2 places (human error cries out loud ;) )
But I have another idea which would solve my current problems and should be much simpler to implement. The possibility to add a Customer to a Theme. And i need to minimize the view per customer just like Themes.
Then i can group by customers and can create themes per customer.
A cool right management where i can choose who can edit which customer and who can edit sprints would be perfect at the end.
Does this make sense to you?
Oh and by the way, thanks for that great support and your help in that brainstorming and testing phase!
understood the problems i think of a much simpler solution now. Because there are not many products, its a single product with customizations for different customers the solution with different backlogs isnt very usefull. The single projects/customer specific things are just too small to handle it as a full product. I also had to plan single user storys from different customers into an sprint (sometimes bugfixing sometimes really small changes). Running Sprints for Customer A and then for Customer B is the goal i want to achieve but in the real world i always have TODOs from other customers, especially when there are really small changes.
Copying User Storys is also not a good idea, because thats a copy and if there are changes i had to do the changes on 2 places (human error cries out loud ;) )
But I have another idea which would solve my current problems and should be much simpler to implement. The possibility to add a Customer to a Theme. And i need to minimize the view per customer just like Themes.
Then i can group by customers and can create themes per customer.
A cool right management where i can choose who can edit which customer and who can edit sprints would be perfect at the end.
Does this make sense to you?
Oh and by the way, thanks for that great support and your help in that brainstorming and testing phase!
Hi Roger
Matt
I understand that requirement, and your idea is sensible for your needs, but unfortunately I don't think that will be a priority for us at this stage. I will add it to the backlog, but unless more people ask for something similar, then unfortunately it's unlikely this story will make it into a release.
I hope you understand, but our problem is that we really need to focus on providing functionality that will work for most of our users. Adding this level of added rights management would be quite complex for users. For example:
- Would a story in a theme that the user does not have access to be visible in sprint view by that user? If not, then the sprint would look incomplete, so this would be complex.
- I am concerned that issuing such granular permissions would in fact introduce lots of problems where people would not understand why they can / can't see the whole backlog.
- Generally there would be a lot of permissions and rights to think about every time you perform a simple function. For example, would new themes by default be visible to all users, or not. Would new sprints be?
I'll continue to keep thinking about a solution for you, but I think the problem is that your needs are quite specific to you. Sorry I am not able to help at this stage.
Matt
Having an opportunity to group themes/topics together to something like a customer (or some other random groupname) would be great. This would enable easybacklog users to use one backlog for multiple customers, modules, products or whatever....
Service d'assistance aux clients par UserEcho
