On 6 Nov, 2009, at 15:25 , Andrea Tomasini wrote:
>> On Nov 5, 6:04 pm, Ash <[email protected]> wrote:
>>>> Right, unless you didn't check the "Strict" option in the Backlog
>>>> Admin... in which case would be right, you will load also all the
>>>> ticket of the selected types which are not explicitly planned for
>>>> other milestones...
>>>
>>> Sadly, that's not true. It's including lots of tickets that already
>>> have other milestones. Because those tickets with milestones don't
>>> have sprints! A requirement won't have a sprint, which causes it to
>>> get selected, even if it has no links to any other tickets, and
>>> doesn't belong to the current milestone. So I really do think this SQL
>>> needs to have the "in ('')" removed when there are no sprints. The act
>>> of so drastically changing what is seen by the absence of a sprint
>>> against the milestone is very confusing and non-intuitive. (Without a
>>> sprint on the milestone I get 160 tickets, with a sprint in the
>>> milestone, I get 2.) So not only would I say the idea that a milestone
>>> report should show non-milestone tickets just because there's no
>>> sprint is a bad idea fundamentally, it's also just plain broken as
>>> that's not what the query does.
>>
>> I can confirm that we are having similar issues. We have a milestone,
>> A, with no assigned tickets of any type, yet some User Stories which
>> are not assigned to any Sprint show up in the Product Backlog for A.
>> The product backlog has its scope set to Milestone and Strict is
>> checked. The User Stories are linked to Requirements that are assigned
>> to another milestone, B, but the User Stories don't show up in the
>> Product Backlog for B. However, if I delete the (empty) sprint
>> property in ticket_custom, the User Stories disappear from the Product
>> Backlog for A, but still don't show up in the Product Backlog for B.
I have tried to reproduce this behavior... unsuccessfully,
1) I created a Milestone A, and 6 Requirements with one story each, and 6
stories disconnected from the requirements
2) I created a Milestone B
3) All Requirements and stories are not planned, and I see nothing in Milestone
A Backlog, nor in Milestone B Backlog
Case A:
- I plan a Requirement 1 for Milestone A, and it appears in Milestone A
Backlog, together with the linked story (if there is no Strict Option) and
without the story (if there is a Strict Option)
- Backlog for Milestone B still show no ticket inside
-> Things to note, that might be misleading, the User Story connected to the
Requirement (when in Strict Mode) is still appearing in the Product Backlog
without the requirement
Case B:
- I plan a Requirement 2 for a Milestone B, it appears in Milestone B and not
in Milestone A, and not in Product Backlog
So the only "strage" behavior, that is actually an improvement is that the top
hierarchical items as the Requirement is not shown in the Product Backlog and
the story, that is linked to that requirement is showing up, letting the user
guess to be a lonely story. Possible solution is to always include the Parents
ticket, in every backlog, also with the Strict Option on (that is the case in
the Product Backlog)
The removal of the condition "not in ('')" it is not so trivial as it seems, as
it must be checked against the ticket type, and this is a dependency that we
wouldn't like to have. At a DB level there is no way to know which are the
allowed property for a given type of ticket, as those informations are stored
in the configuration file. Removing the condition, on the other side, will not
show in those backlog all the stories, linked to the Requirements, which have
not been specifically planned for that milestone, even if there is no "Strict"
option.
The radical approach would be than to remove the "Strict" option... and make it
by default show all the parents (recursively) of every tickets that has been
explicitly planned for that specific milestone, or sprint, and if the Backlog
is global, than show only the ticket which have no planned milestone nor
sprint, and their parents...
What do you think? This would be acceptable to me, and would quite simplify the
backlog handling too...
Best
ANdreaT
--
Follow Agilo on Twitter: http://twitter.com/agiloforscrum
-----
You received this message because you are subscribed to the Google
Groups "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