The recent discussions over how to manage our backlog and sprint planning
have suggested that we should look at whether we can run everything within
Redmine itself. Dmitri and I have been looking into this, and we believe
it's quite possible.
Below is the suggested workflow we've been playing with - it seems fairly
straighforward, and doesn't need any new Redmine plugins to function.
There's also a section on optional extensions and open questions.
We'd like to demo how we think this will work - Dominic, perhaps this
Tuesday's Deep Dive is a good slot?
Greg
···
---
Proposed workflow:
Backlog:
The Issues screen is used as the Backlog
The Priority field is used to order issues
New issues will default to a Priority of “Unknown” to denote the need for
grooming
Saved searches will be added to the Issues tab for
All Open Issues ordered by Priority (“the backlog”)
All Issues with Unknown Priority (“to be groomed”)
Sprint Planning:
A new Version is created in the Roadmap tab
Name is arbitrary text, probably involving the word “sprint” and a date
or number
Target date set to end of sprint
Shared with all projects
Issues are assigned from the Backlog list and targeted to the Version
The Roadmap page for the Version provides the overview of the current
sprint
During Sprint:
Developers assign Issues to themselves from the open issues on the
Version page
End of sprint:
Issues which have been merged to develop/stable are re-targeted to the
appropriate Release Version (e.g. 1.3.1 or 1.4.0).
Any unresolved issues are moved into the next sprint Version
Current sprint Version is closed
Optional Items:
The Backlog field could be used to denote Backlog items if the full list
of Issues is to great.
A new custom field could be used to denote necessary grooming if
management via the Priority field does not work.
The Progressive Projects List[1] could be used to provide an overview of
Versions on the Redmine frontpage.
Remarks:
This workflow mostly uses parts of Redmine that we don’t make heavy use of
today. Greater use of Versions is central, as we make very light use of
this feature today.
Release process should be essentially unaffected as we still keep the
release Versions for tracking issues going into a release. The sprint
Versions apply only to unfinished issues. The use of “tracker” issues which
has been started for the 1.3 RCs seems a good way forward for tracking
cherry-picking.
We do lose the ability to set the Version to a later release for new
tickets, but I feel this is not a big loss, as we frequently change those
targets. Assigning them to a sprint followed by a release seems to make a
more concrete statement of when an item will be done.
Is this not going to be the case immediately, as we have hundreds of
issues with priorities already set?
···
On 03/10/13 13:31, Greg Sutcliffe wrote:
> Optional Items:
> * The Backlog field could be used to denote Backlog items if the full
> list of Issues is to great.
Also what I like is for each sprint there is a single point of comments
and history what was added/removed/commented.
Linking and unlinking bugs is quite fast, even faster than rolling
Version listbox. To link, you just enter issue number and enter, to
unlink just click on the connection icon.
This is an idea, I was not thinking about whole process.
LZ
···
On Thu, Oct 03, 2013 at 01:31:06PM +0100, Greg Sutcliffe wrote:
> Hi all,
>
> The recent discussions over how to manage our backlog and sprint planning
> have suggested that we should look at whether we can run everything within
> Redmine itself. Dmitri and I have been looking into this, and we believe
> it's quite possible.
>
> Below is the suggested workflow we've been playing with - it seems fairly
> straighforward, and doesn't need any new Redmine plugins to function.
> There's also a section on optional extensions and open questions.
>
> We'd like to demo how we think this will work - Dominic, perhaps this
> Tuesday's Deep Dive is a good slot?
>
> Greg
> ---
> Proposed workflow:
>
> Backlog:
> * The Issues screen is used as the Backlog
> * The Priority field is used to order issues
> * New issues will default to a Priority of "Unknown" to denote the need for
> grooming
> * Saved searches will be added to the Issues tab for
> * All Open Issues ordered by Priority ("the backlog")
> * All Issues with Unknown Priority ("to be groomed")
>
> Sprint Planning:
> * A new Version is created in the Roadmap tab
> * Name is arbitrary text, probably involving the word "sprint" and a date
> or number
> * Target date set to end of sprint
> * Shared with all projects
> * Issues are assigned from the Backlog list and targeted to the Version
> * The Roadmap page for the Version provides the overview of the current
> sprint
>
> During Sprint:
> * Developers assign Issues to themselves from the open issues on the
> Version page
>
> End of sprint:
> * Issues which have been merged to develop/stable are re-targeted to the
> appropriate Release Version (e.g. 1.3.1 or 1.4.0).
> * Any unresolved issues are moved into the next sprint Version
> * Current sprint Version is closed
>
> Optional Items:
> * The Backlog field could be used to denote Backlog items if the full list
> of Issues is to great.
> * A new custom field could be used to denote necessary grooming if
> management via the Priority field does not work.
> * The Progressive Projects List[1] could be used to provide an overview of
> Versions on the Redmine frontpage.
>
> Remarks:
> This workflow mostly uses parts of Redmine that we don't make heavy use of
> today. Greater use of Versions is central, as we make very light use of
> this feature today.
>
>
> Release process should be essentially unaffected as we still keep the
> release Versions for tracking issues going into a release. The sprint
> Versions apply only to unfinished issues. The use of "tracker" issues which
> has been started for the 1.3 RCs seems a good way forward for tracking
> cherry-picking.
>
>
> We do lose the ability to set the Version to a later release for new
> tickets, but I feel this is not a big loss, as we frequently change those
> targets. Assigning them to a sprint followed by a release seems to make a
> more concrete statement of when an item will be done.
>
> [1]http://stgeneral.github.io/redmine-progressive-projects-list/
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
We can still differentiate between features and issues for the purposes of
the backlog. As we proceed with grooming, we'd can modify priorities as
needed on issues as well.
-d
···
On Thu, Oct 3, 2013 at 1:42 PM, Dominic Cleal wrote:
On 03/10/13 13:31, Greg Sutcliffe wrote:
Optional Items:
The Backlog field could be used to denote Backlog items if the full
list of Issues is to great.
Is this not going to be the case immediately, as we have hundreds of
issues with priorities already set?
Most things are at the default (Normal) which I think is fine. We currently
have ~20 High, 3 Urgent and 1 Immediate. I don't think that's unmanageable,
but I guess BK will want to say how he finds that idea, since he'll be
doing a lot of the prioritisation.
One Option is to rename Normal to Unknown and re-add Normal, so that all
current Normal issues become Unknown.
···
On 3 October 2013 13:42, Dominic Cleal wrote:
On 03/10/13 13:31, Greg Sutcliffe wrote:
Optional Items:
The Backlog field could be used to denote Backlog items if the full
list of Issues is to great.
Is this not going to be the case immediately, as we have hundreds of
issues with priorities already set?
I'm not so keen on Tracker issues, but polluting Version is a valid point.
Yesterday Ewoud pointed me at http://www.redminebacklogs.net<http://www.redminebacklogs.net/topics/sharing.html>
which
allows us to a lot of the workflow above in a smoother way, but also adds a
"Release" in addition to a "Version". Thus Version is used for the sprint
and Release for the release (obviously).
Since both approaches seem possible, I suggest we demo both the "vanilla
Redmine" as well as the "Redmin + Backlogs plugin" workflow. There's a lot
in common, so I don't expect it will take much more time to demo both.
I'll get a G+ invite out to the community today for the demo.
···
On 4 October 2013 08:23, Lukas Zapletal wrote:
Instead of polluting Version flag, how about creating Tracker Bugs for
sprints?
Just a followup to this - we'll be deploying two new Plugins to Redmine
tomorrow. One is the Redmine Backlogs plugin metioned in my previous email.
Regular Redmine viewers will see some new fields and tabs appearing in
Redmine from this plugin, which should help improve visibility of issues
for current focus, as well as issues completed & targeted for a specific
release. Hopefully it will achieve the aims of both keeping everything in
Redmine and also improving transparency of what is being worked on.
The other is the Github OAuth plugin for new Redmine accounts to
authenticate with their Github credentials (thanks to Marek for the plugin
:P).
> The other is the Github OAuth plugin for new Redmine accounts to
> authenticate with their Github credentials (thanks to Marek for the plugin
>
> :P).
Just small note, existing users can use it for authentication as well. You
just need to have an email address that you use in redmine added and verified
by github.
