Hi,What you want to do can be done by configuring Agilo to suit your workflow, but I'll explain why it doesn't work like that be default. Since the question comes by more often, let me answer in more details then is strictly necessary for future reference ;-)
The short answer: Bugs are treated similarly to User Stories: so create tasks for bugs and developers will be able to 'own' those.
Long answer:Agilo is *not* a bug tracker. It is first and foremost a Scrum project management tool. It just happens to be based on a bug tracker ;-)
The core concept in Agilo is full traceability. That means you can start with a blurry Vision, and then progressively follow it down to a very concrete code commit.
So the basic flow looks like this:- You create a Vision statement, something that tells you at a very high level what you want your product to be - From this vision you create Requirements - high level 'needs' that your product will need to satisfy in order to be successful - The Requirements you break down into User Stories - concrete descriptions of how you will satisfy those needs for specific type of users - The User Stories are broken down into Tasks - 'real' pieces of work you can solve at your desk ;-)
Now from a workflow point of view, these items are planned like so:- The Vision is a wiki page. It is revised on a very slow cycle, as the vision usually stays the same for very long periods of time. - Requirements are planned in the Roadmap - you make a rough plan on which need you want to solve when, depending on market opportunity and your business model. You do this by planning you Releases in the Roadmap - dividing it into several Sprints - To the Sprints you add User Stories that you want to work on, based on the Requirement you have in mind for Release
So where are the bugs?Inevitably, software development will lead to bugs. There are two ways of dealing with bugs: squashing them the moment they appear, in- sprint. This should be done for all bugs that are noted immediately. Some bugs do not pop-out during development, but after deployment, or 'in-production'. If they are critical, you of course stop what you are doing and fix them.
If they are not-critical, you prioritize them, then plan them inside your sprint plans. They should be prioritized and planned by the Product Owner in collaboration with QA or Testing - not *by* QA or Testing, as the PO needs to have control over the backlog if you want him to be accountable.
A Bug is broken down into tasks, and then we are back at the short answer ;-)
Regards, Garbrand On Aug 19, 2009, at 12:30, boflynn wrote:
Hi I've used a few bug systems in the past. In agilo, I'm not sure how things are meant to work? A tester logs a bug in agilo, assigns it to a sprint. A developer (with TEAM_MEMBER rights and AGILO_CREATE_BUG rights and AGILO_TICKET_EDIT rights), for some reason can't go a pick a bug off the list and take ownership of it? They also can't update the bug to fixed? In fact, under the Actions section on the bug edit page, there is only one option Leave as New? For some reason someone has to be assigned to the bug for the developer to be able change the status? Surely this isn't the way its meant to work? Every other bug system I've used, the developers can just go in and pick a bug off the list (everyone owns all the code, etc. from agile) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the GoogleGroups "Agilo for Scrum" group. This group is moderated by agile42 GmbH http://www.agile42.com and is focused in supporting Agilo for Scrum users.To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/agilo?hl=en -~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
