August 11th, 2015 by inflectra
People often email us to ask if it is possible to have more than one owner in SpiraTeam when assigning a requirement, test case, incident or task. They also often ask us why we named the field 'owner' rather than 'assignee'. Well these two decisions were actually thoughtfully made and not just at random.
We decided from the beginning that we it was very important that users in SpiraTeam (or SpiraPlan) were accountable for the artifacts that were assigned to them. If a person is assigned a requirement or user story then they need to be the advocate for that story, they need to be able to describe what it's intention was, how it should be developed, and how it will be accepted as done (hint: acceptance test). When the product owner, developer or team member has questions about how it should be built, the owner needs to have a deep contextual understanding of the actors involved and the goal it seeks to accomplish.
Consequently we decided in SpiraTeam to name the field 'owner' rather than merely 'assignee'. The former we felt conveyed the true meaning behind what it means to own a requirement or a test case, and for an incident or task, the same understanding is true. If you are assigned a bug to fix then you will feel an obligation to fix it and hand it back, but if you own that incident, you will fix it, test it, look for side effects, make sure all unit tests are written to prevent a recurrence in the future. Only then will you feel that it is truly 'done'. Assignee feels like an accident (I was assigned this task), owner feels like possession (I own this task).
Words have meaning and shape how we interact with a system, in SpiraTeam, users own artifacts.
The second question we get asked a lot is 'why do we only allows a single owner per artifact in SpiraTeam?'. Well this was also a deliberate choice. In our experience, when you assign an item to multiple people to own, in reality, neither of them actually feels that they own it. In a previous job, we used to say that "multiple owners is the same as no owners". Another person I knew would put it more colorfully, "I always need to have one throat to choke!"
In our experience when you have multiple people in charge of a task, neither feels responsible for it and neither is 100% compelled to make sure it gets completed on time, or to communicate if something gets in your way (Blocked in SpiraTeam parlance). So to ensure that every task, requirement, incident, test case, and test set is not forgotten, SpiraTeam will insist on a single owner. As mentioned before, multiple people in charge = no one is in charge!
So next time you think about wanting to have multiple owners, simple break down the requirement into multiple tasks, or decompose the incident into multiple associated incidents, or convert into a requirement with multiple tasks. If an item is big enough to need multiple owners, you're better off analyzing it and breaking it up so that each part of the larger item has its own owner.