How do we know what to work on and what not to work on?
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 an answer.
Short answer: Only items on the backlog should be worked on.
Follow-up question #1: Who gets to add things to the backlog?
Answer: The 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?
Answer: 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 else?
Answer: It depends J. 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?
Answer: These 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 our customers.
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.
Example Backlog:
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:
- Research reporting tools to replace existing one
- Create sample report in BIRT
- Create sample report in JasperReports
- Add button to print report on Category screen
- Create final report in selected tool
- Create test cases
- Test case #1
- Test case #2
- Test case #3
- Update 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.
Summary
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.
Thoughts?