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


19

If you reduce a team from 7 to 4, especially if the reason is something outside the team, the best course of action is probably to treat this as a completely new team. People will need to change into new roles, find a new way of working together, cover fresh weaknesses caused by those leaving, find out who is in charge of what, and all the other problems ...


19

If you do development work in the sprint, you should estimate. If you don't, then it's better you skip on providing your own story points estimates. You can help your team with information and advice, and support them to reach consensus, but you should let the people that do the work perform the estimates, otherwise you might be influencing them in one ...


18

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


14

Choose your battles carefully You mention you are new to the team and new to the organization. It will take some time before the team fully trusts you and your judgement. If that has already happened then you have more arguing power to support your point of view. If you are still very new, then have patience and wait a while. It's also very important to ...


13

Two things jump out at me. First, the end result of a Spike is not a shippable product. Spikes are used to learn, and do research. The end result is an answer to a question or finding some information or gaining knowledge in a given area. That doesn't mean that there's not an output associated with a Spike, but it's almost certainly not a shippable product. ...


12

in your practice, do you use the aforementioned disaggregation? Why or why not? I encourage teams to focus on estimating consistency rather than on having a complicated estimating approach. There are a number of reasons for this, including: Complicated estimates encourage people to believe that their estimates are more accurate and when they prove to be ...


11

Question: Do you give each team member a user story A see an anti-pattern here. As a Scrum Master, you don't have to assign stories & tasks to team members. It's their job (under your servant leadership) to self organize and pick sprint backlog items. They can use swarming techniques, they can pair program, they can breakdown technical tasks into ...


10

I really liked Todd's explanantion on how to deal with such situations: Focus on Sprint Goal, instead of specific Stories. When prioritising these stories, some will fit better to a concept of a single goal than others. So, instead of focusing on priority or velocity, focus on Sprint Goal. Ok, it's kinda the same as focus on priority. Besides, avoid the ...


10

I want to supply a bit of a purist answer not because it is necessarily more "correct" than some of the others, but to give a different perspective. In many modern implementations of Scrum, the next 5 sprints are assumed. We plan very large projects into a set of sprints. This does deliver some value, but it misses part of the core point of Scrum: ...


10

Relative estimates (points) are useful because they tend to give a better approximation than absolute estimates and tend to be easier to work with. Points are just an approximation however, and they make most sense when looked at in aggregate and over a period of time. I wonder if you are making too much of the details. Some suggestions below. I certainly do ...


9

The official answer to the problem is: There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to. However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your ...


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


8

The Scrum Guide says that the Development Team are responsible for all estimates. Where the SM isn't also a member of the dev team then it should be up to the team to what extent the SM participates. It's reasonable to contribute to estimation discussions if you have something useful to say but I would suggest you take a back seat so that the team feel that &...


7

Those "phases" you describe sound very non-agile to me, but there are instances where a single person cannot complete a story and needs help from another team member even in super-agile environments, so lets just assume it is indeed necessary: Take those points and discuss them in the next retrospective. There is no silver bullet, you solution will look ...


7

For the official answer, I'd take a read in the Scrum Guide under The Sprint, including Cancelling the Sprint. (https://www.scrumguides.org/scrum-guide.html#events-sprint) Scrum does allow for clarifying or renegotiating the Scope of the Sprint, as long as it doesn't put the Sprint Goal at risk. That said, I can't imagine that you can switch 70% of the ...


7

Spikes are typically time-boxed, so it is usually easy to work out the impact they will have on a sprint. For example, you might time-box a spike on a new technology to be one developer for one day. The idea with a spike is to do just enough investigation so that the team is then able to estimate the work. If at the end of the spike the team still does ...


7

With a team of four working on several different products you could consider using a Kanban-based approach instead of Scrum. Scrum works best if you have a cross-functional team with a quantity of work for a single product that makes it necessary to plan a co-ordinated sprint a week or two in advance. With your team however, prioritisation is presumably much ...


7

Actually "story points" is exactly for not doing what you are trying to do :) The idea behind it is this; Estimations aren't accurate. Here's an article of mine about this. Trying to estimate takes a lot of effort. There's a misunderstanding that, every story point should match with an effort-based metric like hours, minutes, days, etc. That's ...


6

Welcome to PMSE! Good question. It may be a duplicate but I could not find it so I will answer. I can tell you how I coach teams to handle it. Unfortunately, the story is bigger than the time remaining. Ideally, the developer would like to make an early start on work that will be planned for the next sprint I coach to bring it into Sprint. ...


6

This is not the purview of the Product Owner (PO). The PO should not care how the product is built - that concern lies with the Development Team. The PO should only care about what is built in what order. In my experience, purely development tasks such as these should be created by the Dev Team, not the PO. If something can be stated in a way that ...


6

This is a really good question, but there is no definitive answer. Have the conversation with your Product Owner. Explain to them the situation and offer them a choice. The Product Owner may say that the difference in importance between Story C and Story D is not significant, so they are happy for you to swap them around for this sprint. Alternatively, ...


6

The short version is that it is the development team's decision. Let's say you have this story: As a user with a telephone program installed, I want to automatically dial a number when I client on it in the application so I don't have to remember the phone number and key it in. As a product owner, that encompasses the user's need perfectly, so I'm ...


6

Your Product Owner should be available during planning to answer any questions that appear concerning the stories. If question could not be resolved, because the Product Owner was not there or could not sufficiently answer the question, then the story is not ready and should not be in the sprint. A placeholder is not a good idea. Sprint planning is making a ...


6

I don't think there's a mathematical function to take in effort, risk, complexity, and uncertainty in order to return a single value in story points. I also don't think that approach makes sense. One way to think about it is to reduce the factors. Uncertainty is one form of risk, so you don't need to identify both. At worst, you'd look at three factors - ...


5

Not every story in a sprint needs to result in a (potentially) shippable product. But as a sprint typically contains multiple stories, it should still be possible to have a (potentially) shippable product at the end of the sprint without having one after each story is completed. The objective of a spike is to gain knowledge that can be used later when ...


5

Also, how do week-long Sprints with mid-week starts and stops follow each other without constantly moving which days of the week are used? For instance: Sprint 1: Tuesday to Tuesday, next sprint starts Wednesday. Sprints always start on the same day of the week. That means they must end on the day before that. M-F or T-M or W-T or Th-W. When you're ...


5

Imagine you have planned a sprint, prepared every detail, broken down the epics into stories and already presented your roadmap to management and promised the releases ahead. In the sprint planning you also give 10 features to your engineering team. The developers tell you... If I were the PO who had done this, I would first of all own that I had ...


5

Quite simply, start the Sprint with what you have. However, your Product Owner (and the business) must learn the lesson that the pipeline of work is never finished. Run an ad-hoc retrospective to discuss how you ended up in a situation woth redundant cycle times. Are stories not play ready? Has the backlog been exhausted? Are no further requirements ...


5

It isn't clear from your question if you are following the Scrum framework, but if you are then the Scrum Master should be pointing out the following from the Scrum Guide: The Product Owner is the sole person responsible for managing the Product Backlog. The team can ask the Product Owner to add items to the backlog. It is up to the team to create a ...


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