27

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 ...


22

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.


13

Sutherland decided to make the meeting at most 15 min long. In his own words: [...] the meeting couldn’t last more than fifteen minutes. We wanted it to be crisp, direct, and to the point. If something required further discussion, we noted it and met further after the daily meeting. The idea was to get the most actionable and valuable information in the ...


9

The Scrum Guide mentions 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. If you keep the same train of thought, that translates to a maximum of four hours for a two week sprint. Events are time boxed in Scrum so that people stay focused on the activity. Imagine if ...


6

Having gone through something similar myself, here are some considerations. I'll try not to get too wordy but there are some aspects of Scrum that need to be brought up. Making this sort of change can be extremely beneficial, but first and foremost needs buy-in from the developers. If they are not supporting changes it won't work, and Scrum should be run ...


5

A four hour long meeting is harmful Four hours is way too long for a productive meeting [1]. Here's an excerpt from an article by FastCompany: What’s your record for longest meeting? Can anyone beat my four-hour marathon? (I bet many of you can!) When it comes to meeting pain points, length often tops the list. How is it that meetings tend to go on so long,...


4

The reasoning behind the 15 minute limit on daily scrum meetings is, as Bogdan points out, that you should never need more than that to achieve the purpose of the meeting, which is just a daily "sync" to keep everyone up to date on who is working on what and check to see if anybody needs to co-ordinate with anybody else on any of the details of ...


4

TL;DR 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 ...


4

In my opinion, no. I once took over leadership of a team that had 4-hour biweekly planning meetings, and it was miserable. No one is effective towards the end of a 4-hour meeting, and it led to plenty of bad decisions. I was eventually able to bring it down to an average of 90 minutes (in a 2-hour slot) and the resulting work was greatly improved. The key, ...


3

For a team that's done minimal pre-meeting preparation, is working on a new project, and/or who are new to working together, 4 hours for a 2-week sprint seems reasonable. It's better to waste a few minutes in a meeting than waste a few days of a developer's time during the sprint because a task wasn't clear enough or if technical blockers weren't discussed ...


3

How to Sequence Spikes So, how long should a developer spend on that investigation? If the team can't estimate a user story—more canonically, a Product Backlog Item (PBI) in Scrum—with "close enough" accuracy within about 5 minutes during Sprint Planning or Backlog Refinement, the story either needs to be decomposed or replaced with a story ...


3

In Scrum, this type of work is considered Product Backlog Refinement. Per the Scrum Guide, it "usually consumes no more than 10% of the capacity of the Development Team", but this isn't a hard time box like other Scrum events. There's also no guidance to how to use this time - I've seen cases where the entire team books time to review Product Backlog Items ...


3

The first thing to note is that you don't have to plan everything before you start the sprint. Mike Cohn has a really good post on why teams don't need to think of everything in sprint planning. Don't be afraid to make a start on the sprint and then get the team together every now and then to do additional planning. This allows the team to adapt during the ...


3

The Scrum Guide defines it as a timebox, meaning the outside time is the maximum time to spend. That being said, if you're going to just continue sprint planning without calling it that anyway, you're just hiding the disfunction. I would be inclined to make what seems like the best call in the moment and then reflect as a team about why it occurred. For ...


3

Anyone who has studied for any of the Scrum.org certifications knows the answer to this question because it frequently appears in the practice assessment [paraphrasing] Q. When does the next Sprint begin? A. Immediately after the current Sprint ends. Therefore the Sprint time-box encompasses all the other time-boxed events. The Daily Scrum occurs every day,...


3

The answer from Thomas Owens is correct. However, I would like to add that depending on the team organization, I think it's acceptable to do some of the ceremonies outside of the 2 weeks considered as being the sprint (or whatever length your sprint is). For example, I've encountered teams preferring to do the planification for sprint N on the last day of ...


3

While my gut tells me that your team may benefit from shorter sprints, I would caution that you're being very prescriptive. That is, you've already decided that going to 2-week sprints will fix your problems and you're now trying to get people on board. It'll be better for the team in the long run if you help them develop good habits identifying and solving ...


3

As far as I understood your situation (you explained in the comments) the problem you are trying to solve is the missing feedback from the PO. It seems that you only get it end of the sprint. If you want more feedback you do not necessarily have to shorten the sprint. You could Introduce a PO Acceptance as part of the Definition of Done so the PO checks ...


2

Teams sometimes dislike the idea of shorter sprints as they worry that a larger percentage of their time will be spent in meetings. But the length of the sprint ceremonies should be proportional to the length of the sprint, so they will not be spending any more time than before. There may also be technical concerns. Some teams worry that 2 weeks is not ...


2

Short answer: You start the sprint with what you have at the end of the planning session. During the retrospective, you evaluate why the planning overran the timebox and what can be done to reduce the likelihood that it happens again.


2

Some suggestions: Automate as much as possible of your regression testing. This leaves the QA's free to focus on new functionality. This then allows the team to test as they go along in a sprint, rather than waiting for the end. Think carefully about the way you use version numbering and environments. For example, some teams I have worked with will do a ...


1

The purpose of the limited timebox is to force the team to break down larger items into smaller ones. 2 weeks is a long time for research. I usually look for research tasks to be measured in hours, not days, let alone weeks. You may need to consider exactly what it is you are researching. Some common ways to approach this include: In pure research, what ...


1

Yes, per the Scrum Guide, all the Scrum Events (Sprint, Planning, Daily, Review, Retrospective) are completed within the Sprint timebox. I prefer to start the Sprint on Wednesday and complete the Sprint on Tuesday. By starting and closing in mid-week, the team avoids competing w/ 3 day weekends & for the US, the Monday holidays.


1

A big plus of a team sizing stories is that different people will have different perspectives on the problem and solution. Those need to be discussed to find the best option. One developer doing that work and presenting it sounds kind of self-defeating. The team should have enough knowledge to size most if not all stories without extended preparation. If ...


1

I have encountered a few similar problems in one of my projects. Like yours, one of my team had testing efforts piling up towards the end of the sprint. When stories were incomplete (i.e, testing not done in this case), it caused stories being carried forward to the next sprint, disruption to the flow, delay in delivery, coordination issues(between QA and ...


1

Obviously your first hurdle will be getting buy-in, both from upper management and from the Team. But assuming you already have that... One problem you might run into is QA being under-worked at the start of sprints when there's not much to test, while the developers are under-worked towards the end, when most of the stories are in QA. While 100% ...


1

With respect to releases, you don't need to release after every Sprint. The output of a Sprint in Scrum is a Potentially Shippable Product. The keyword there is "potentially". Every completed story should meet the definition of done (which should include all related tasking, such as documentation updates, unit testing, integration testing, acceptance testing,...


1

TL; DR The Scrum Master's role is to encourage the Development Team and the Product Owner to work together to resolve issues cooperatively, rather than trying to solve the problem through authoritarian decree. Don't turn a real problem (e.g. poor feedback loops) into a X/Y problem by assuming that the cause is your Sprint length. This is a logical fallacy, ...


Only top voted, non community-wiki answers of a minimum length are eligible