I cannot speak to your particular situation but yes, it is pretty common that not everything is done.
This is in fact a logical consequence of the structure of the team, and you being a developer are in a prime position to appreciate it.
Load and delay
If I were to ask you “do you run a server at 100% load?” you would likely laugh in my face. So I might ...
I'm going to slightly disagree with Bogdan's answer.
The Scrum Guide does say that:
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
We normally think in weeks, so I translate "one-month Sprint" to "four-week Sprint". However, it goes on to say that if the Sprint is ...
From the Scrum Guide:
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
All of the events are included in your Sprint timebox.
Working sprints that end/start mid week is usually more effective/efficient than ending on a friday and starting on a monday for several reasons:
It makes the last minute rush to complete work more painful and less desirable for the development team (eliminates the excuse of, "hey we can finish it over the weekend).
Reduces the risk of paying weekend ...
I was wondering if it's a good idea to name Sprints with user-friendly names instead of using numerals like Sprint 1, Sprint 2, etc.
No, it's not a good idea.
A sprint is a container where Product Backlog items are temporarily stored for a brief duration. A sprint may produce some project artifacts, but the sprint itself has value only as a time-...
In addition to the questions that Daniel poses, I'd pose a different one first:
Is the team achieving its Sprint Goals?
The Sprint Goal for a team following Scrum is the objective that should be met at some point during the Sprint by implementing Product Backlog Items selected for the Sprint. It can help focus the team's efforts toward specific work and ...
In my team, if the backlog was exhausted, we always had the following to fall back on:
The team can invest time and create a prioritized backlog of technical / architectural debt in your systems
Work on technical debt items created using point 1 (above).
Improve the automated continuous integration and continuous process. In the world of infrastructure as ...
Jeff Sutherland, the inventor of Scrum, developed a pattern called 'Illegitimus Non Interruptus':
Explicitly allot time for interrupts and do not allow more work than fits within the allotment. If work exceeds the allotment, abort the Sprint. - Scrum Patterns Group
You will likely have historical data on how much time you should allot. Look at frequency ...
Name the Sprint after the Sprint Goal
If you want to name a Sprint, I agree with the accepted answer in the programmers.stackexchange.com thread that you should name it after the Sprint Goal. As the Scrum Master, I keep pushing the Product Owners to come up with a well articulated Sprint Goal. I always start my Sprint Planning sessions by inviting the ...
Missed estimates are not an opportunity for blame, but rather an opportunity to inspect your process and adapt it to fit the requirements of your organization. The Product Owner, the Scrum Master, and the Development Team must all work together to learn from the failed sprints.
It seems like the entire Scrum Team is working under some ...
If you are following Scrum as defined in the Scrum Guide, the Product Owner cannot simply add stories to the Sprint Backlog. The Sprint Backlog, which is created as Sprint Planning as a negotiation between the Product Owner and Development Team while considering past performance and forecast capacity, is owned exclusively by the Development Team.
If work ...
It is common, but it isn't right. Here are a few things to consider that may be contributing to this challenge:
Is the team focused on delivering a potentially shippable product increment each sprint or just doing work in a larger project? I hear a lot "it doesn't matter, it all has to be done on the deadline". If I hear that, they're probably right. They ...
In the context of Scrum, a Sprint is a timebox. It has a start and it has an end. Once a Sprint starts, it's timebox is fixed - it will end when it is scheduled to end. There is no concept of adjusting the end date of the Sprint because things come up.
Based on this and the problems that you're describing, I do have some suggestions.
First, I would ...
Scrum doesn't enforce batch sizes on stories the way some other methodologies do, so individual story sizes can vary dramatically. The important thing is that the aggregate of all stories should fit within the defined Sprint length, and the team is expected to adjust its processes as needed to optimize both estimation and Sprint Goal completion.
There are different conventions I've seen used. In my opinion, even having one is completely irrelevant, besides giving you something to refer to in discussions (which may or may not be a good thing!)
Use a «Sprint N» or «Iteration N» convention:
Pro: Easily generated
Con: Is anyone going to remember what you did in iteration 23? It's almost like not naming ...
The Sprint backlog is a forecast, not a commitment
In the 2011 revision of the Scrum Guide Jeff Sutherland and Ken Schwaber made an important change. They changed the word "commitment" to "forecast" in regard to the Sprint backlog.
The term commitment has two bad consequences:
The stakeholders expect to have every single item delivered at the end of the ...
So this is something I'm dealing with right now in AOL. The constant desire of business to measure seeps even into agile organizations. The key is to make sure you are measuring in a way that does not damage the fabric of agile for the sake of measuring.
We must always be very careful and mindful of Goodhart's Law: "When a measure becomes a target, it ...
From the Scrum Guide:
During the Sprint:
No changes are made that would endanger the Sprint Goal;
Quality goals do not decrease; and,
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
The changes you mention fall into the last category, unless they endanger reaching the sprint goal. If the last ...
Perhaps a more accurate way to put it would be that story point estimates are imprecise. If you have a 5 and a 3, that may or may not be the same size as an 8.
To make this less confusing, let's start with a non-numeric scale like T-Shirt sizes. XS, S, M, L, XL and so on. We can agree pretty easily that a small and a medium t-shirt do not get you a large t-...
No guarantees on this one, but here is what I would try:
Either they are not understanding your documents or they are not doing the work and using the documents as a scapegoat. It is a little extreme but ask for a restatement of your documents along with their anticipated approach. Get this by the next day as a precursor to them commencing work on the ...
No, Daily Scrum with Three Questions is not a sign of team immaturity.
Yes, Daily Scrum with Three Questions is valuable, even if you with your team want to switch to Extreme Programming.
No, Daily Scrum with Three Questions is not a sign of team immaturity.
In reality, I don't understand, why Daily Scrum with Three Questions should ...
I have seen almost any day but Monday and Friday, because people want to leave early on Friday (assuming you have flex time) and might come in unpredictably late on Monday if they are contractors that went home over the weekend and only arrive in your city on Monday morning. Those days are also prime targets for single days off to have a long weekend and in ...
In Scrum we look to create product increments each Sprint, not simply to do work. The direct solution to your question from the Scrum Guide is that you should have cross-functional team. That is, all skills needed to deliver a full product increment should be on the team.
There are circumstances where this may not be possible and you are stuck in the ...
I totally agree with Michael and Mark. Both nailed the problem with the ask for a restatement of your documents along with their anticipated approach. They're clearly not understanding the requirements. The problem is... are they trying to understand beforehand? If they're not analysing the requirements and jumping straight to the dev, they'll have a hard ...
I gave Sergey's answer a vote, solid ideas.
I think Sergey's answer works well at smaller scale, in an Enterprise class program or multi-scrum team program you might have a little more success if you bring in Release Planning as a formal activity and do the majority of your work in the Backlog Refinement (Story Time) meeting. Here's why-
So it would go, ...
Since you're doing Scrum, let's look at the guide:
Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
Why does scrum take such a strong stance against the sort of thing you're trying to do?
Your team is not regularly ...
the backlog is populated by the project manager
Scrum, as it's defined, doesn't have a role called "project manager". There are only three roles - Product Owner, Scrum Master, and Development Team. The Product Owner is responsible for maintaining the Product Backlog.
and can contain entries as abstract as he wants, with various degrees of ...
Scrum is not intrinsically about doing more work faster, although high-performing teams often do. Like most agile frameworks, Scrum is about doing just enough of the right work.
Measuring the team against a target velocity is a Scrum anti-pattern, as is measuring productivity from the number of backlog items or story points completed. Instead, you ...
You actually have two questions. One is about time-boxing, and the other is about estimation.
Time-boxing and estimation are the very essence of Scrum. If you aren't adapting those two practices for your team, whatever you're doing isn't really Scrum.
Tools and Practices Aren't Silver Bullets
[Incremental development] just doesn't seem to bring ...
It really sounds like the Scrum Master and the Product Owner have both bought into the velocity and utilization trap. Break the cycle.
Dissecting the Product Owner Role
The PO wants to know how many hours programmer X has available during each sprint and exactly what he will do with them.
Not his business in a Scrum shop. He is part of the Scrum ...