1. General
  2. Idées
+3
À l'étude

It woudl be good to have a Release Version field

-7778 il y a 13 ans • mis à jour par Matthew O'Riordan (Founder) il y a 12 ans • 10
It would be good to be able to assign a story to a release tag, which can be just a text field. For example, it can be used to plan release 1.1 vs 1.2 or core release vs customer specific one. The backlog could then be sorted using this field.

Solution

Solution
À l'étude
Matthew O'Riordan (Founder) il y a 13 ans
Hi there

We are a bit reluctant to add more fields to the interface as it's already pretty crowded as it is.  However, saying that, a few people have been asking about a separate priority field, which perhaps could have a dual purpose of release / priority, which you could then sort by.  Can you explain a little more about how you use this release field so I can understand the process?

Matt
Solution
À l'étude
Matthew O'Riordan (Founder) il y a 13 ans
Hi there

We are a bit reluctant to add more fields to the interface as it's already pretty crowded as it is.  However, saying that, a few people have been asking about a separate priority field, which perhaps could have a dual purpose of release / priority, which you could then sort by.  Can you explain a little more about how you use this release field so I can understand the process?

Matt
Ian Kershaw il y a 13 ans
There seem to be two things we would find very useful:

1. Some way of managing features by release rather than sprint. Either with something like a theme which was the release scope or by creating another backlog which is the master backlog and allowing stories to be easily copied into a release specific backlog.

2. Some way of specifying risk and business value fields to aid with prioritisation of stories.

Thanks,
Ian.
Matthew O'Riordan (Founder) il y a 13 ans
Hi Ian

Thanks for the feedback.  We are really doing our best to cater for everyone, however that does sometimes mean we can't solve all problems for all people.  However, if I can understand a bit more about what you're trying to achieve, then I hope I can find a solution.

In response to your points:

1. Managing features by sprint: We are considering adding releases, this has come up a few times from users.  However, we are mostly being asked for releases as a way to group themes together so that any stories that are assigned to a theme, which in turn is assigned to a release, is grouped by that release.  And once a release is marked as complete, then all the stories for that release are no longer shown in the main backlog.  What are you trying to achieve with releases so that I can understand why you need releases?

2: Risk & business value: This request has come up a few times, but we've not yet resolve this unfortunately.  See http://easybacklog.userecho.com/topic/83641-add-business-value-field-theme-importance/ and http://easybacklog.userecho.com/topic/94379-drag-and-drop-ranking-of-backlog-independent-of-themes-eg-t1s1-t2s2-etc/.  If you read the latter one, this is what we are planning on implementing, the ability to specify the order of your backlog independent of themes.  Whilst this won't explicitly add risk / business value fields, it will allow you to prioritise independently.  Would this solve the problem for you?
Ian Kershaw il y a 13 ans
Hi Matt,

Thanks for your prompt reply - it must be a challenge managing everyones individual requests, but hopefully these dialogues will help you find a simple solution that works for most people.

To you points

1. Managing features by sprint. What you are proposing may work. Here's an example scenario:

Theme : User login/logout
Story 1: As a user I want to be able to login and logout...
Story 2: As a user I want to be able to click a forgot password link...
Story 3: As an enterprise user, I want to be able to login and logout with my organisations single sign on....

As you can see, Story 1 might be in an early release, whilst Story 2 might come in a later release and so on. Perhaps we're not using Theme's as intended?

2. Risk & business value: Yes this approach say with a value 1 to 100 per story might work. If we have a huge backlog, it really helps to be able to focus on what is going into the next release by organising by business value and risk. It also then help to prioritise which stories should be started first in any given release. It's much quicker to set a value whilst creating the story than to re-read each story every time. Again, perhaps there is another way to solve this problem?

Thanks,
Ian.
Matthew O'Riordan (Founder) il y a 13 ans
Hi Ian

In regards to point 1, I'm not really clear on what the issue is.  If story 2 is part of a later release, why is that a problem if it's part of the user login/logout theme?

In regards to point 2, I feel your pain.  Big lengthy backlogs are very hard to maintain, and I'm not sure we have a solution at present for this.  The problem with numbering systems is that if you want to introduce a bunch of stories above others, then potentially you have to spend loads of time renumbering old items to shift everything around.  Hence we are considering a drag and drop solution instead that is divorced from theme ordering, but will allow you to maintain your backlog ordering easily.  Do you not think this would work for you?  If not, why?

Matt
Ian Kershaw il y a 13 ans
Hi Matt,

Sorry I wasn't very clear on point 1. It's really just a way to manage the backlog - so that stories that are in a future release remain on the product backlog, whilst stories for the current release are in the release backlog. That way, when doing iteration planning, you don't have to pick them from an enormous list. Drag and drop prioritisation (point 2) might go some way to solve this, but it's also good to have an idea of what is roughly in scope for any given release.

Point 2, yes I think this might work. 

Thanks for considering our feedback.

Ian
Matthew O'Riordan (Founder) il y a 13 ans
Hi Ian

I understand what you are after, that makes sense.  When we introduce releases (a little way off), then we will allow a user to assign a story to a sprint or a release.  Thus if you want to filter by current release only, you will be able to do that easily.

Thanks for the suggestion, however I thought it would be worth noting that we're not planning releases for a little while yet, so unfortunately you will have to deal with a big backlog for now.  Sorry!

Matt
Stefan il y a 12 ans

Any update on when adding this grouping into "releases" will come ?


This is exactly what we are looking for. After a while, the backlog becomes crowded with completed theme/stories. It would be really good to be able to hide completed releases.

This is especially a problem since the principle of the backlog is to have the highest priority on top. If everything at the top is "completed" you have to scroll down which beats the principle.


Thanks,

Stefan

Matthew O'Riordan (Founder) il y a 12 ans

Hi Stefan


Well unfortunately releases never made their way to the top of our backlog unfortunately.  Can you tell me a little more about what you think you need releases for, and how you would see them working?  If it's simply to hide stories that are completed, filters can be used for that, although we are going to be improving the filtering capabilities soon as well.

Matt

Stefan il y a 12 ans

Hi Matt,


Releases are another way of grouping stories. You group stories into sprints which are releasable increments but a release is a larger goal that makes sense on it's own.

Let's say you have a product that is at version 1.7. You plan the next release 1.8 which has a logical and consistent set of features. You break these down into stories and then plan several sprints in which you implement them. You might have a sprint zero at the beginning and a hardening sprint at the end. In our case a release typically takes 7 to 10 2 weeks sprints.

Another example is for large projects that are broken down into several releases. 


As a Product Owner, you want to plan your release (see the aggregate points it requires, projected completion date) and track your release burn down (or up) rate to track how you are doing. Depending on this you might move features (themes) or stories in and or out of the release.


Today we could emulate that by using separate backlogs, one per release. But it makes it more complicated to move stories and you loose the aggregated stats. If you manage several products each with a roadmap of releases it becomes a lot of backlogs.

Finally if you pull data from the API into other tools you need to maintain the grouping between those related backlogs somehow.


On a side note, I think this is also related with the stories priority issue. For me a release is where stories are grouped together in a prioritized way, while themes are where stories are grouped in a logical way (are related functionally or technically but not priority). I see the release feature as a way to solving the dual theme/priority viewing issue.

The hierarchy would look like:

Backlog:

   -> Releases:

      -> Stories in priority order

   -> Themes:

      -> Stories logically grouped

So a release "view" would give you the priority/date/effort view of the backlog and the theme "view" (the current one) would give you the function/feature/effort view of the backlog.

In the sprint planning view, you would have the "release" view on the right, either grouped by releases or with some form of decorator to indicate the release a story belongs to.


Hope this make any sense...

Thanks,

Stefan


Matthew O'Riordan (Founder) il y a 12 ans

Hi Stefan


Sorry for not replying sooner, but we have considered what you said, and I really appreciate you explaining how you use releases.  We'll do what we can to accommodate when we review how we do story grouping and prioritisation which is in our backlog.


Matt

Service d'assistance aux clients par UserEcho