As my team becomes more responsive to the business needs
placed upon it I realize that I haven't clearly communicated the guidelines I'd
like to see in place and why I believe the guidelines are helpful. Here is a
recent clarification I sent out (modified for a more general audience).
The Question: How
do we know what to work on and what not to work on?
This question has come up a number of times in every project
team I've ever worked on or with. It is a good question and one that deserves
Only items on the backlog should be worked on.
#1: Who gets to add things to the backlog?
Product Owners have the right (and responsibility) to add or remove things from
the backlog. They take input from many people outside the company, inside the
company and inside the department.
Please, please, please do not interpret this as
reason to not tell the Product Owner your great ideas or lobby them to raise or
lower the priorities of certain backlog items. You have a unique insight to the
products we create and we need your input.
The primary reason behind this approach is that we want to
make it crystal clear what we are working on. There is a concept in
astrophysics called "Dark Matter" (http://en.wikipedia.org/wiki/Dark_matter)
which essentially is stuff we can't see but affects what is going on. Dark
Matter in software development is all the little things that we do, but don't
track that end up making the project late. The dark matter isn't necessarily
"bad", we just don't see it until the project is late and someone asks why. The
backlog and support queue are ways to "see" more of the dark matter.
Follow-up question #2:
What about issues that come from support?
issues are just another form of work that may have a higher priority
than what you are currently working on.
Note that all support issues are not created equal. If it is
not obvious check with the Product Owner and the support manager to understand
the urgency of the situation and the requested turn around time. If it is
possible try to finish the task you are working on so you don't have to try and
pick it up again in the middle later.
Currently we track these issues in the support queue and
that is fine. Just be sure to assign the issue to yourself if you are working
it. Your project manager may choose to replicate this information in the
project tracking tool so that we have a consolidated place to review this data.
Follow-up question #3:
What happens if <insert executive here> asks me to work on something
You will get requests from people from time to time that aren't on the backlog.
If you know the answer off the top of your head feel free to answer. Generally
though please redirect them to the Product Owner (politely of course). Once
again, the idea here is to make the work visible and the Product Owner needs to
be able to help balance the workload against other existing priorities.
Follow-up question #4:
How do we schedule things like unit tests, JVM upgrades, product evaluations,
build servers, and meetings?
types of things are definitely required to build our software, but they are not
typically backlog items into themselves.
These things tend to group in 3 categories: big technical
changes, non-story related work and tasks.
Big Technical Changes tend to be things that affect
the system horizontally, i.e. you have to touch almost the whole system in some
way. Examples of this are significant runtime or database upgrades, new
persistence mechanisms, new security models, etc.
Big Technical Changes in our future are things like migrating
to Subversion, upgrading Sybase ASA to version 10, upgrading PowerBuilder to
version 11.2, and migrating to Eclipse 3.3.
These happened infrequently (2-3 times/year), but have a
potentially significant impact on the project schedule. Because of the possible
impact Big Technical Changes need to be coordinated with the Product Owner in
the form of a Technical Backlog which gets scheduled in the same way as any
other backlog item.
Non-story Related Work tends to be things that help
us get work done better/faster but is smaller in scope than big technical
changes. Often these kinds of changes don't directly affect the code we ship to
Examples of this are improving the build server, upgrading
Bugzilla and testing framework improvements.
These happen about once per month and can be a separate
backlog if big enough or can be attached to a story as a task.
Tasks are the technical things we need to do in order
to complete the backlog. The Product Owner owns the backlog, but the task list
is owned by programmers, testers and writers. The Product Owner doesn't muck
with the tasks and nobody else mucks with the backlog.
Tasks may directly or indirectly affect the code we ship.
For the most part I expect everyone has a basic handle on what tasks are.
As a Manager I want to Print the Category Setups so I can
refer to them when I am not at the computer.
Tasks I'd envision:
reporting tools to replace existing one
sample report in BIRT
sample report in JasperReports
button to print report on Category screen
final report in selected tool
documentation & help files
Researching the tools are tasks in the first report that is
worked on. Also note that tasks 2 & 3 probably didn't exist until #1 was
mostly complete, similarly tasks 7-9 and #6.
You can also see some of the elements of "Done" that we
defined in the past.
There aren't any meetings, unit testing, refactoring,
compiling, designing or breathing in the task list because those are just part
of the everyday life of creating software.
Only work on tasks related to backlog items in the current
iteration and urgent support issues. The Product Owner manages the backlog,
everyone else manages the task list.