I see several fundamental management issues in your example:
if a Scrum-Addicts manager signs a "hard-deadline" contract, but adds only a safety margin of 33% in a situation where "a new system is involved", that is pretty reckless.
the availability of delivering at least x% of the features after one month could have been used to negotiate a contract ...
Create a branch
Merge daily from trunk to your branch and resolve conflicts.
Work until it's done. Your branch may be outside core development for several sprints.
Merge back to trunk.
There's no getting around the fact that it will probably get ugly. I don't envy you. In my experience, when you drastically change a project, it's easier to ...
One of the value statements of the "Manifesto for Agile Software Development" is :
Customer collaboration over contract negotiation
The fact that Scrum-Addicts LLC negotiated a contract instead of establishing a collaboration with a customer makes me question their agility.
One thing is clear : Agility needs to be accepted by EVERYONE. Agility is not ...
At the beginning of the sprint there is nothing to test yet
Really? You have no requirements to validate? No discussions to have with your customer? No wire-frames to evaluate? No test plans to think about?
at the end of the sprint there is typically nothing or very little
left to develop/fix
I have never been in that place in a project. No more work ...
Not every task can be done in an (artificial) 2-week sprint, so common sense is called for. If it can't be broken down any more, and it must be done, just get on and do it. The process is not more important than the end result, and should be seen as a guideline rather than a never-to-be-broken law.
Why are the backlog items not inserted and prioritized before sprint kickoff? Wasting developers time is not fun. Let your team leads work with the product owner and project manager a few days beforehand to prioritize stuff. This goes for planning who is on each sprint team too.
Why is it taking a day to break things out into tasks? If you have a reasonably ...
Just do a 3, 4 or 5 week sprint. Who cares? You're obviously convinced that nothing can be done in a shorter time-frame, so stop fighting it.
Just don't tell your fellows at The Royal Society of Blind Agile Adherance.
Make estimating easier
Break your sprint planning down.
Do you need to estimate the individual tasks? I've done sprint planning two ways:
Stories are estimated in story points and then tasks are estimated in hours
Stories are estimated in story points and tasks simply fall under that with no estimate
Of the two, I prefer the second option. I find that ...
The first point is that Scrum is all about optimizing the team, not each individual. If the team is productive and efficient, it doesn't matter much if someone is idle at the start or end of the task.
However, on every team I've been on, there is always plenty of work. Let me address a couple of your specific concerns:
At the beginning of the sprint ...
You're right - 5 hours in Sprint Planning for a 1 week Sprint does seem like a long time. The Scrum Guide time-boxes Sprint Planning to 8 hours for 1 month Sprints and says that "for shorter Sprints, the event is usually shorter". If you consider the ratio, a good target may be 2 hours of Sprint Planning for a 1 week Sprint, but there's no fixed timebox.
First off, vacation isn't a problem, it's a reality. The burn-down chart is supposed to reflect the reality of the project's progress, and if the project progressed less during one sprint compared to another due to vacation, a proper sprint burn-down chart will reflect that.
Secondly, vacation (along with other administrative functions) is expected to ...
Bring something from the project backlog into the sprint (after discussions with scrum master and project owner).
The size of the item you undertake will depend on how much time you have. If there is nothing small enough create a sub-task of a bigger task to get it started (ie do some of the preliminary work).
Alternatively create some tasks that make the ...
Who is to blame?
Managers, legal dept, accountants - take your pick...
I know the example is somewhat contrived but the fact that the company could walk away without paying a dime if they weren't 100% satisfied should have rung immediate alarm bells as should mixing waterfall and agile thinking.
Customers want to have their cake and eat it - they're happy ...
Planning is about doing commitment and about splitting committed user stories to tasks.
have a planning session with him after he is back.
Definitely no. Planning session after he is back doesn't make sense because commitment had to be already done.
have a planning session with him before he goes on annual leave i.e. before sprint planning.
If you have the luxury of delaying the refactoring, I suggest focusing coming iterations on adding unit test and automated integration tests to the point where you can comfortably refactor the codebase, and then refactor in a single sprint.
With "item", I suppose you mean "task".
Planning optimism in software is as old as software itself. The good thing about scrum is that you are facing it soon and create visibility of it: this is why the teams velocity is based on past data and not future estimates.
To complete a story, you also have to complete the tasks that turn out much harder than ...
I'm working on a project loosely following the scrum model.
To make it clear: Your managers probably told you about Scrum but what you perform is not Scrum.
How long does this typically take?
Sprint review meeting + Sprint retrospective meeting ends current sprint. In short sprints they should take something between 30 minutes - 1 hour together. Next ...
The situation you describe is toxic. This sort of bargaining ignores reality and the expertise of the team, it willfully conceals information from the team and organization at large, and it inhibits the team from improving over time.
If you want to city http://www.scrumguides.org/scrum-guide.html as an authority I would highlight:
Only the Development ...
What should we do if a item in scrum takes longer then expected?
Assuming that by item you mean story, at the end of the sprint you typically put it back in the product backlog (and likely plan it for the next iteration). The team scores zero points for it in the current iteration.
Another alternative, if the story is big enough, is to slice it vertically....
The most common means of tracking a sprint is to use a Burn-down Chart. Basically you total up all your estimated tasks that you've committed to for the sprint. As you complete each task, you subtract the estimated points and plot the new point. The goal is to have zero points left at the end of the sprint.
Is my understanding of average velocity and sprint commitments correct?
Yeah, you have the gist of it.
If not, what have I gotten wrong?
The thing you overlooked is that story points are the things you get done. It is nigh impossible for everyone to work on stories right up to the end of the sprint. If you're doing things right, most of your developers ...
IT projects deal with unknowns; some of these unknowns are even unknown unknowns.
What does that mean?
Take for example a toy bridge for your model railroad. There are all parameters known to you:
You know how big the valley is
You know the material of the mountains, their height, stability etc.
You know how much material you need
You know from earlier "...
At one company where I worked, we had monthly sprints/releases, and we named them alphabetically after internet memes. The releases I worked on recently were:
That added a bit of fun to the process, especially when it came time to name the upcoming iteration.
After a while thinking about this, I came with the following convention:
<year> CW <starting calendar week> - <ending calendar week>: <goal> (<version>)
Version is optional.
So you end up with something like:
2013 CW 27-28: Improved reporting and dashboards (v1.5.1)
2013 CW 29-30: Redesigned gadgets (v1.5.2)
This syntax ...
When we started practicing scrum, we kind of dropped our specialisms and individual projects, instead we started working as one team. While I am more of an expert in Unity3D and C# and we have another team member who is more skilled with Node.js (etc), we ensure that we are spreading the knowledge of the projects.
One thing agile and scrum are in favour of, ...
In an ideal agile team members are comfortable with all technologies used in a project and any task can be executed by (almost) any member of a team. If that is the case, after sizing tasks in the backlog, defining the iteration and team members picking their first set of tasks from the backlog, you can just leave the rest of the tasks in the bucket and they ...
First of I would not have hard rules about it; the whole point of scrum is to allow you to adapt to the situation. So you should be able to modify the sprint backlog during the sprint if you absolutely must (like you forgot something critical).
But saying this modification to the sprint backlog during the sprint should be resisted. The whole point of the ...
The confusion is due to ambiguous language.
The Sprint Backlog has two levels of detail. First, it is a list of Items (User Stories) that the Team has committed to deliver. Second, it is all the TASKS that the team intends to do in order to deliver each of those stories.
So when people talk about the Sprint Backlog, they should really be clear about what ...