Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Q&A for AMOS SS13
Please use this thread to ask questions about the AMOS project; we prefer to answer publically if the question is of interest to everyone.
One of you asked:
- Does everybody have to a SM and RM? Or does only the PO have to be SM and the SD RM? Or is it up to us who will do these jobs?
Everyone should be the Scrum master at least once.
Typically only SDs have the ability to be a Review manager, so it is fine if only SDs play it.
Please try to give everyone equal opportunity
- Where should we put features which were not in the Sprint Backlog but are finished already? Again in the Sprint Backlog for the next sprint or directly in the Feature Archive?
Well, a “finished feature” can directly go into the Feature archive.
However, only a PO can confirm that a feature is “finished”. So the PO needs to write a feature description, and then it needs to go through a review session. Thus, you should add it to the Product Backlog or directly to the Sprint Backlog, depending on when you can take care of the review.
Hope this helps,
is it allright for two or more developers to be working on the same feature if it cannot be divided further and is in the same time too large for one sprint?
Two developers working on the same feature is normal—it is called pair programming.
Three seems excessive and like standing on each others feet but if it is a difficult feature, you’ll at least figure out how you should have subdivided it beforehand!
Yes, not a problem how you organize your work is up to you.
Two questions on AMOS:
1)Where should we put features which are not finished yet but on a good way of completion? Our idea was to do it like this:
Sprint Backlog: Feature XY, Effort 8
→ could not be completed!
Sprint Backlog:Feature XY.2, Effort 3
Feature Archive: Feature XY.1, Effort 5
Feature Archive: Feature XY, Effort 8
If we just put it back to the Product Backlog and then to the Sprint Backlog and not add it to the Feature Archive, some effort will be lost. This means that effort 8 would not be in the release plan as real effort because we calculated a new remaining and less effort of 3 for the current sprint. Effort 5 will then be lost.
- The estimated effort should not be personal, but the real effort is personal - how should we handle it?
Our current assumption is that features fit into one sprint. So you shouldn’t plan a feature across multiple sprints. Rather, you should cut it into smaller pieces and distribute these pieces as individual features over your upcoming sprints. (Please be reminded by the discussion that we are simplifying by having only features and no feature/task distinction). If a feature does not get implemented within a sprint, it gets put back into the product backlog, where it might be picked up for implementation again, right away.
In your example, lets assume you only realized during implementation that it was too big. Your suggestion is one way of handling it. Another variant, which I prefer, is if you do not artificially split features (temporarily) but do track effort spent on it. So, in week 3, feature XY was first put back into product backlog, then picked up again, and is in the sprint backlog with a total estimate of “8 (5)”, where the “8 (5)” signifies that you already implemented 5 of 8 story points. (Assuming your estimate of 8 story points remains the same). This way you know you only have work of size 3 left to do. You also don’t clutter the feature archive with features which, due to reprioritization, might never get finished.
The estimated effort should actually be size. In a given team, person A may be able to finish on or more features totaling a size 5, and a person B may be able to finish one or more features totaling 8 story points. Taken together, the two-person team has a speed of 13. So the problem is not so much personal vs. non-personal but can you pick features that fit the size of what people are capable of doing within a given sprint.
From Ann: One of the teams wanted to know if you want them to update their release plan as they get new information (such as not completing something during a sprint) so that the burn-down calculations are correct, or whether they can leave it as is.
My answer. Yes please. It is a bit laborious, but not much. You should gain that visibility of where you will be for the mid-term release.