Re: [PLUG] Backlog in Redmine?

[Rich Freeman <r-plug@thefreemanclan.net>]

On Wed, Jan 8, 2014 at 10:34 PM, Kevin McAllister <kevin@mcallister.ws> wrote:
> The worst part about backlogs is their tendency to build up cruft (wishes that
> everyone knows will never be worked on but are politically unable to be deleted)
> makes iteration planning difficult as you wade through the mess.

I wonder if this is an agile thing as I've seen projects at work deal
with this sort of issue in general.

Agile is ultimately a project management methodology as much as it is
a development methodology (at least, that is my sense of it).  There
is a tendency to therefore optimize the tools used for the purpose of
making project management easier.

A list of outstanding issues has merit even if you never intend to fix
any of them - they document the state of the system.  I've seen a
tendency at my workplace to want to start out every project with a
blank slate (sharepoint sites, bug lists, test repositories, etc).
This has the virtue that the project team doesn't have to think about
anything that ever happened in the past, but it has the vice that the
project team is blind to anything that ever happened in the past.
Also, when you need to pull up historical data (often for legal
reasons in my industry), then it is scattered all over the place as
every release on a system was handled as if it was the only release
that would ever be done.

I've even seen requirements documents where the requirements are
organized purely by release (section one is features added in version
1, section two is features added in 1.1, and so on).  That means that
if you want to understand all the requirements that pertain to adding
a customer to the database you have to grep the entire document and
hope they don't contradict.

So, be careful when organizing repositories simply to make the job of
getting the next release out the door easier.  Granted, not all
projects are as dependent on formal correctness - in my industry if an
auditor finds contradictory requirements or isn't convinced that the
system as delivered matches the requirements they can shut you down.

Just a random thought inspired by what you posted.  The issue isn't
really Agile so much as single-minded focus on release execution with
little thought to the bigger picture.

Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug