Hot answers tagged

10

It sounds like you are at the extreme thresholds of Scrum. According to the Scrum Guide, a Development Team that has fewer than three members has less interaction or doesn't need as much interaction as a slightly larger team. Therefore, you may not see benefits from using the Scrum framework in a way that slightly larger teams would. It also sounds like the ...


7

I see two possible options. First, don't break down the item. In this case, the work item (the story, ticket, whatever) represents the minimum valuable delivery of the work and can be estimated by the team and worked on. The team may break this out into subtasks (either in a tool or informally) and work on it, but the work is tracked at the level and is ...


5

Improving the standup What my question is, how to make this more as a team sync and less as a team rapport? I don't think there is enough detail in your question to answer that. You've described symptoms (some people feeling like they aren't being heard) but haven't explained the root cause. Are some team members joking around without listening? Are they ...


3

I'm going to lean towards breaking it down. Yes what they asked for is all of it and they might not find any final use for the parts. I like to break it down anyway. Here why: At the end of every sprint you show something. That something might be a miserable failure but you show it when you're supposed to show it. That showing gives them some idea where ...


2

Just make sure to create a story for the ad hoc work and assign points to it before adopting it into the current sprint as an expedite issue. This way you will maintain velocity. If you had other sprint goals, these will just move to the next sprint. There is not really a problem here. You can push back a bit though and let them explain why this cannot wait ...


2

There are a number of aspects to the points you've raised so far. Developers will raise a number of issues in the standup and elsewhere. Part of your job as SM is to filter the noise from the genuine issues. Some developers always seem to have something to complain about while others may mention the same issue time and time again. Standups should be ...


1

In the simplest terms possible, when new work is added to the sprint, some work already in the sprint needs to be taken out. Take the work that was added, do your best to give it an appropriate amount of story points, and then remove that amount of story points from the sprint backlog. Depending on the size of the request, this can probably happen without ...


1

The contents of a Sprint are not necessarily fixed at the end of Sprint Planning. Based on what the team knows about their capacity and ability to do the work, they have selected items and chosen a Sprint Goal that the Development Team feels is achievable and the Product Owner feels is appropriate to deliver at or before the end of the Sprint timebox. In an ...


1

You should talk about this in your retrospective (or whatever regular process your team does to inspect and adapt), and come up with a solution that works for you. You already aren't doing "pure" scrum because you are doing design work in your standups. That's perfectly okay. Keep adjusting your process based on feedback. The way I see it, you're really ...


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