Again it is important to emphasise that we are NOT documenting problems, but anomalies that we are experiencing with the process template in the environment and in the manner we are using it. It is therefore important to define whether the default behaviour is as you would expect it to be (in this case skip this blog post) or whether our change warrants a second glance.
In today’s scrum stand-up meeting (Sprint 2 focused) one of the feature area leads had his blood pressure go through the roof as the sprint backlog item query returned a long result set. It was only when we scrolled to the right that we noticed that the default query returned both sprint 2 (current) and sprint 1 (previous) work items as part of the result set as shown:
Not as expected in our environment and therefore we made another query change.
Our change to the process template
For the default sprint backlog query and all specialised custom versions thereof, we added the linked work item clauses as shown. Basically we are saying we only want to see work items, of type task, under the sprint 2 iteration path and linked tasks of the same sprint (current):
The result was more in line with expectations as shown:
We are looking at the best way of implementing the concept of Epics. Watch the space … 🙂