According to Mike Cohn
It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case.
Accordingly to Scrum.org:
The Scrum Goal is the creation of productive and creative ...
Facilitate Communications; Don't Proxy Them
In your specific example, the Scrum Master should function as a communications facilitator, not a proxy for the team. The Scrum Master often functions as a switchboard operator by:
Helping team members to identify points of contact outside the team for collaboration and refinement of Product/Sprint Backlog Items.
In Scrum, are stories supposed to be a replacement for product requirements?
No, they are not.
One of the Agile values is "Working software over comprehensive documentation". One reason being that it's hard to define what the product should do from the beginning. Once the clients see the software, they will want changes because they get a better ...
I am personally adverse to the idea of ever saying a sprint 'failed'.
Scrum uses the term 'inspect' 27 times, and 'adapt' 16 times over the course of the guide.
Scrum also has no notion of 'failure', and the only reference to failure in Scrum is listed here:
Failure to include any of these events results in reduced transparency and is a lost ...
Before I begin the answer, I'd like to point out that user stories are not part of Scrum. They are not mentioned in the Scrum Guide, but are commonly used to represent Product Backlog Items. In Scrum, the Product Backlog and its Product Backlog Items are "the single source of requirements for any changes to be made to the product". The Product Owner is ...
Jeff Sutherland, one of the creators of Scrum, provides an answer in his book Scrum: The Art of Doing Twice the Work in Half the Time:
And so my team embarked on what we called "Sprints". We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and then stop to see where we were.
Scrum is based on an empirical process control system. It assumes that not everything is known and that knowledge will emerge over time. Trying to specify every acceptance criteria in exact detail may not be possible and may take way more time than needed.
It's not possible to know all acceptance criteria in advance.
Instead, Scrum explains that the ...
In Scrum, are stories and acceptance criteria supposed to be a replacement for project scope and product requirements?
Scrum does not specify the format of requirements other than that they should be in a product backlog that is an ordered list of everything that is known to be needed in the product.
The reason that user stories are popular with teams ...
If you are using Scrum, then you must have a Sprint Goal and produce a potentially releasable Increment by the end of the Sprint timebox. These are things that are core to the Scrum framework.
But you don't need to use Scrum. Perhaps Scrum, as it's defined in the Scrum Guide, doesn't make sense for your team as you are focused on support and maintenance. ...
From the Scrum Guide:
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
So basically, in each Sprint it's not enough to keep yourself ...
Well, the Scrum Master should help with impediments. You have given no indication that this is an impediment. What makes the email to the head of IT an impediment, unsolvable by the team themselves?
The Scrum Master is not the teams errand boy. If the team cannot do it themselves, then the Scrum Master is their escalation step.
If it is sufficient to ...
A failed sprint means you did not reach the sprint goal.
That can mean all stories but one were completed, but that one was critical to reach the goal.
Only you can know whether this is the case here.
Keep in mind that the stories pulled into the sprint are a forecast of what the team should be able to do. Saying "all stories must be done" as some ...
Yes we can, planning in Scrum is done at three different levels: daily planning, iteration planning; release planning.
From team's point of view, the release planning gives us the direction, the iteration planning gives the structure and the daily planning gives the context for the next days.
All the planning allows risks to be identified early and so we'...
My suggestion would be to pick a 'theme' for the fixes that is important.
This sprint our goal is to improve the user experience with search
The focus for this sprint would be the defects relating to search. There may be other types of defects being worked on, but the team knows that it is the defects relating to search that are key to the ...
A research spike is intended to reduce the cone of uncertainty for future work. It is not intended to deliver shippable increments of anything. Treating the output of a spike as anything other than input to story planning/refinement is a Scrum implementation smell.
Time-Box Your Spikes
As an empirical control framework, Scrum is heavily reliant on ...
If the quality of the product isn't good, is the Scrum Team fault
It is never the stakeholder fault!
According to the Scrum Guide (2019), the Scrum Reviews are
"informal meetings" in which the stakeholders are invited to
participate and collaborate. Being "informal meetings" we expect
the requests, needs and ideas presented by the stakeholders
to be ...
The product owner is responsible for defining all the items in the backlog with enough detail for the team to be able to work on them. Acceptance criteria is part of those details. The product owner needs to have these clearly expressed before work begins.
Of course it's also the team's responsibility to make an effort to understand the items from the ...
Why are you talking about blame?
Your Question reads, to me, like "Something went wrong. Who do we blame?"
The only situation in which "responsibility" (read: blame) should be relevant is when it is necessary - namely, when selling to an external party. In which case, the only valid answer could ever be: "Check your contract". This is a question for a ...
Scrum doesn't require use of "user stories", but is a common practice
The Scrum Guide (https://www.scrumguides.org/)
does not mention user stories at all. Using Scrum you can choose any
way to represent the expected behavior of the software:
data flow diagrams;
The Sprint Goal is a focusing tool for the Development Team. It is not necessary for all work selected for a Sprint to be aligned with the Sprint Goal. In fact, I usually recommend that the Sprint Goal should be something that can be met through the completion of at most about 60-70% of the Product Backlog Items selected for the Sprint. If the Development ...
I wrote about this recently elsewhere, and I'll revise and extend my remarks for this answer.
First, let's define project-based software: It is software that is meant to be defined, planned, developed, and delivered, and then the project is considered 'done'. A common metaphor used is relating it to building a building.
Scrum is an agile methodology, and ...
One thing I wish to add to the accepted answer, is that you shouldn't take the meaning of the word "Sprint" literally. You see from Thomas Owens' answer that it was a name attached to the way they structured they're work.
In a sprint in a sporting event, participants prepare for the sprint (e.g. warm-up), start the sprint when the signal is given, cover a ...
You're right that the Scrum Guide is rather vague when it comes to how involved the Scrum Master is when it comes to removing impediments.
Personally, I believe that the Scrum Master should, as much as possible, be hands-off for how the team works. The Scrum Master is a single individual. In some organizations, this person may be working as a Scrum Master ...
Scrum intentionally does not layout exactly how the team will build the product. There are a number of reasons, but most pertinent to this question is that what works for one team may not work for another. Similarly, what works with the tools of the early 2000's may not apply as well today.
One of the reasons we work in iterations is because it gives us ...
I suspect there is no single answer to this question.
Individuals are different. Some may find that doing a code review is a welcome distraction from their coding tasks. Others may struggle with the context switching or may not enjoy doing reviews.
Teams are also different. I can see the nature of code reviews varying depending on many factors including:
I think DevOps defines the best practices here: specifically the principle of small batch sizes.
In other words, if the batch sizes (code commits) are small, then the code reviews can be frequent and short.
I would live with the frequency because that's more of an Agile thing and it's OK! Build a team culture that supports it. DevOps also tells us to ...
What is the definition of work done in Scrum
Work that satisfies the Definition of Done, which is defined by the Team.
The problem with this is that work being closed on a daily basis is not shown on the Burndown chart
This is the correct behaviour. From Scrum's perspective, an incomplete story provides zero value, so the burndown shows zero progress.
Is there some place in this method for new workers who should first "load" tons of information in their heads before they really can start working?
Scrum is not only a framework for incrementally delivering value it is also an excellent tool for incremental learning.
Teams often start out delivering minimal value as they are going through a sharp learning ...
Backlog and 'Fail-fast' are at the very foundation of agile development.
In a way, 'Failure in a sprint' is actually a desirable quality.
Failed sprint, according to me, is a well-executed sprint.
Failure facilitates continuous improvement.
100% success of sprint happens in 2 cases:
Team is complacent and is not pursuing ambitious goals.
Scrum and agile development are a response to the problem of software projects being extremely difficult to schedule, and most project schedules being little more than a collection of guesses. Switching from waterfall to scrum isn't losing your schedule, it's admitting that you never really had one in the first place.
Software isn't like construction, where ...