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.
AMOS SS14 Q&A with Lecturers
Please use this thread to ask administrative questions on AMOS.
For self-help questions among students please use the “Agile Methods and Open Source” subforum.
We will monitor this forum and try to respond in time.
Mid-term Release Plan
One team emailed me some questions about the mid-term release plan, which according to the schedule should be included in the planning artifact due on 1 May. The paraphrased questions were: will there be additional information given in the project management lectures, is it possible to see the slides before the lecture so that there is more time to do the release planning, and how is the planning graded?
The answer to the first question is yes. For the second question I will refer this to Prof. Riehle, but I will note that one resource which is available to you whenever you want to see examples are the AMOS projects from previous years, many of which can still be found on Github. For the last question, let me note that agile development is designed to deal with a changing situation. Therefore I don’t expect your planning to be completely accurate, only realistic. Over time, I expect to see improvements in the planning process as your team becomes more experienced and applies all parts of the process, including the retrospective.
I expect to have the slides teaching release planning out soon so you can look at them before the deadline.
Realizing time is short, I already postponed the mid-term release planning by one week so you should have sufficient time to do the planning based on the available materials.
SCRUM Master Role
amongst several teams, there is confusion about assigning the SCRUM Master role. During the past couple of weeks we have heard conflicting feedback. Should this role be taken by developers at least once or is this only a PO role?
Re SCRUM Master Role
The last time we did the AMOS class we asked that everyone take the role of the Scrum master at least once, although teams might choose to give this role more often to the POs because the Review & Release manager role is only taken by the SDs. However, we did indeed have some internal inconsistency on this point this year, so in checking the planning documents I have not been looking to see if each person has taken the role but only if the roles are to some extent rotated.
Thank you for your feedback, Ann.
We have another question concerning the mid-term release. Does this have to include any special tags? Will teams present their releases in class or is it our own responsibility to inform our industry partners? Is there anything else we should know?
we have some questions concerning the release plan.
How detailed are we supposed to plan our next sprints?
Should we already plan the user stories for each sprint?
For our project, it seems to be very hard to plan that detailed and in the end we are pretty sure that we cannot stick to the plan, which we would be able to do now.
Are we (as POs) supposed to estimate the sizes of the sprints? Isn’t it correct to write the sizes from the planning poker into the estimated size column of the release plan?
Re Mid-term release
The answer to your first question can be found in either the slides 02B - Server Setup (on StudOn) or in the Deliverables Checklist (linked from the Course Index).
For your second question I will ask Prof. Riehle to answer.
At this point you should have a release plan for the mid-term release completed. The final release plan is due the same week as the mid-term release. Release plans should be created by assuming that the team will continue to work at the pace which has been established and planning the appropriate number of story points for each sprint. You might check the student discussion board as well, as one team shared their experience there.
Of course you will discover that the plan changes. Maybe the team couldn’t complete everything one sprint, or a story was overestimated, or priorities have shifted. This is fine. In slides 03C - Development Planning, the release plan is described as evolving. You will have to check it every week to ensure that it still reflects your best guess about the project’s future development.
A release plan is not a promise that you will deliver exactly what is written there. It is a reasonable prediction based on experience. Over time, the team should become better at estimating story points (if real and estimated effort remain far apart, this should prompt discussion) and also at completing a fairly consistent number of story points each week.
The actual estimate which you use when the task is accepted by the software developers and moved into the Sprint Backlog is based on planning poker and the input of all software developers. However, as a PO, you want to get some idea of how large the tasks are before you enter the planning meeting. This allows you to do some planning, and also to revise stories which turn out to be bigger than you thought.
This is alluded to in slide 19 of 03C - Development Planning and in slide 29 of 03A - Process Management and explicitly mentioned in the Deliverables Checklist.
Ideally over time the SDs are becoming better at estimating and also the team is converging on a shared understanding of story points, so you should be able to ask any SD for a pre-planning estimate.
The purpose of the mid-term release is to have a product release (experience) before the real product release experience (the final release).
Key aspects of a product release are that you (a) actually release (you can decide not to release a sprint, not release the product means you didn’t manage well towards a stable version and (b) your release plan is in order, cleaned up, and a good record of what happened.
(a) is the most important part. The most obvious mistake is to keep pushing ahead like in any prior sprint and not focus on having a stable version. If you do that, you may not be able to release, and your software remains riddled with bugs.
So, you release. To the industry partner it doesn’t matter, unless you decide to take the time for an extra session. They should always be able to find the latest version for testing at osr-amos.cs.fau.de
There won’t be any presentation in class. Demo day is the last day of class.
Ann already answered this:
I’d like to add that for estimating features that are for later sprints, the POs can do it, though typically, the POs sit down with a senior developer and go through the features for the remaining sprints. It is obviously not going to be as good as if you played planning poker, but it is typically good enough and doesn’t require the full team.
Verify your Git repository before the deadline
We know that for many of you, Git is new, which means it is easy to make mistakes. Twice we’ve seen instances where teams thought their projects were available, but the new material wasn’t actually part of the master. Hannes and the Git lecture slides can offer advice on resolving problems, but first you need to be aware that there is a problem. Therefore it is highly recommended–if you are unfamiliar with Git and responsible for deliverables–that you clone a fresh copy of the repository and verify that it looks as expected. Try the following steps for verification:
Create a clean temporary directory
Clone your repository
Make sure all necessary branches and tags were fetched
Make sure that the tagged commits contain the right files and are indeed the version you want to release
Try to build your fresly checked out repository
Hello @ all,
quick question about the final release plan:
Are we supposed to make the final release plan only for the sprints 8-13 or one big one including all sprints (also those that have already been in the mid-term release plan)?
thanks in advance!
The final release plan covers the sprints following the mid-term release, to the end of the class (8-13).
We view the mid-term and the final release as two distinct releases.
Hence the release plan for the final release should only cover the second release.
amount of story points in sprint planning
We have a question based on the feedback to our planning document, that Ann asked us to post here:
How are we supposed to deal with overly ambitious sprint planning? Is it the responsibility of the POs to step in when we feel developers are taking on too many features for a week? We would not want to influence developers’ grades by not allowing them to code the amount of features they would like to do. But it is us, the POs, who get (negative) feedback, when planning is too ambitious.
I think the first question is: Is it overly ambitiuous? As a PO, you can tell the developers that this seems overly ambitious to you and they can disagree or agree and you can have a discussion then. Obviously, wild swings in story points taken on suggest an overly ambitiuous sprint.
We value consistency over one-time efforts. You can argue that for some reason you have more time to spend but we really would like you to put in consistent hourse. So, we wonder what is going on when we see wild swings in story points and no consistent development speed.
In terms of grading, we consider the whole team, both POs and SDs on this issue.
Adding to what Prof. Riehle said, the focus of this class is the process. Everyone in a team is responsible for the process. It’s important for the team to have a relatively consistent velocity because this enables planning and reduces burn-out. In the beginning there are often more fluctuations as the team settles into its pattern, but as the term progresses the sprints should end up being fairly uniform in scope. When I see an ambitious sprint, two thoughts come to mind. First, the team might not be following the process, and might be trying to put in extra work now. Second, the planning poker may have failed, and developers might not actually believe that the commitments they’ve taken on are accurate. The team should reflect on why the SDs want to commit to more work. Sometimes it is easy as a software developer to underestimate the amount of work involved.
Of course we are happy when the SDs are enthusiastic and want to complete more work. A previous term we saw a very interesting impediment, along the lines of “The SDs were too motivated and took some extra tasks from the top of the Product Backlog.” Of course this should not happen like this–the POs should be aware if the SDs want to take on more tasks–but it does show one possible way of dealing with optimism: taking a more conservative number of points and then, if the tasks are completed quickly, approaching other SDs to see if help is required or approaching the POs for additional stories. This is also how we would expect an SD to respond if the work was vastly underestimated and was finished too quickly.
Quick question on the final release plan:
Do we need to adapt the final release plan every week if something changes during a sprint (i.e. some features are not implemented or new features are added?)