Hot answers tagged

24

It sounds like you have team members from high power distance cultures. People may not speak up when the boss is in the room because their values require them to listen and follow, not to advise or lead. You may even notice it happening between junior and senior team members or between yourself and team members. Read more about power distance here: https://...


15

Analysis There is a chilling effect when he is here. Am I overreacting? Should I just try to build up the confidence of the team? or should I ban my boss from the retrospective? In my experience, this is a classic case of missing the forest for the trees, and mistaking process problems for interpersonal ones. Let's enumerate some of the issues that ...


7

Do stories generally get done by the end of the sprint? If so then leave things alone. Tracking the sprint burndown always feels to me like micro-management. The team are responsible for meeting the Definition of Done for stories by the end of each sprint. Track the product burn-up (or burn-down) on a sprint by sprint basis, not on a day by day basis.


5

The answer to this question depends a lot on the people in the team and on the boss. Normally, a Scrum team should not contain people with special roles, especially a boss. The balance of power gets messed up and you can kiss self-organization goodbye because a boss will have a tendency to decide on matters, and want to have the last word in various ...


4

Discussing problems during Daily Scrum is perfectly fine. When a team member mentions some impediment you can stay right after the Daily Scrum and discuss the issues. From Scrum Guide: Here is an example of what might be used (during Daily Scrum): ... Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? The ...


4

There is a single sprint goal, to prioritize the sprint backlog. The team goes about what the do and when, but they need guidance. The goal is not from the user's perspective, the goal is about what the PO wants to achieve with this sprint. That might be something from the user perspective. It might not. Having sprint goals in advance is counterproductive. ...


4

You need to look at that is happening inside of your sprint. A few things that might provide insight include: How quickly are items moving into your sprint? If everything is moving into progress on day 1 and 2, this may indicate that your team is trying to divide and conquer. In this approach, everything starts on day 1 and ends on the last day by design (...


4

Seeing things like "Ready for UAT" and "UAT" in a workflow always raises a concern for me. UAT is almost always outside of the control of the development team, and often even outside the control of the development organization. These activities shouldn't be part of a team's workflow if they are beyond the control of the team. I'd ...


3

I might suggest that talking about this at the retro might be in order. Retrospectives and the action items that come out of them are often focused on process and how to improve it. However, it can be easy to forget that retros are a part of the process as well, and it is worthwhile to tweak them if they're not working the way they should. Now, it may a ...


3

If the presence of any team member is reducing the performance and productivity of any activity, remove the problem. To expand on my answer a bit: a chilling effect brought on by a "superior" in the room is not uncommon. A lot of factors play a part in that, including the degree of "rank" gap between the boss and the team, cultural ...


3

If you are making large scale changes to your underlying infrastructure code then The Mikado Method might be useful. Methods and Tools did a review on it. There is a book on it Mikado Method for Legacy Code by Ola Ellnestam & Daniel Brolund Another book Working Effectively with Legacy Code by Michael Feathers is also a useful resource.


3

I think it's generally true that the emphasis of the Sprint Review is on the product and the Sprint Retrospective is on the process, but that doesn't mean the Sprint Review is exclusively about the product and the Sprint Retrospective is solely about the process. The Scrum Guide does state that during the Sprint Review, "the Development Team discusses what ...


2

Problems or things which went wrong, should be raised in the retrospective. The retrospective is for the whole team internally. The results can be shared with others. The retro is the event with the green (what went well) and red cards (space for improvement). Inside a retro the are no hirachy, many teams exclude management from that meetings, so everybody ...


2

There isn't a straightforward answer to this type of question because a lot depends on: the nature of the problem. Is this a technical problem? Is it a product related problem? A problem regarding the processes, practices or tools? Is it about the team? the target audience. Who needs to know about this problem, and most importantly who needs to solve it? ...


2

As a Scrum Master, the only time when I would look to ban somebody from a retrospective is if the team asked me to do it. My recommendation would be to first coach the team and the boss on the importance of making the retrospective a safe space. The team (or the boss) may then act of their own accord. If that doesn't help I would make the team's behaviour ...


2

Two options I see: A) Split your stories into smaller stories. B) Make your Sprints longer. If you're unable to get your stories done in a single Sprint, then either your stories need to be shorter (note the 'S' in INVEST) or your Sprints longer. Or both. As always, since you're doing Scrum, bring it up in the Retrospective. State the issue, hear opinions, ...


2

TL;DR This is a good question because it exposes a common misunderstanding about Scrum theory and the value of a Sprint Goal. To illustrate your use case, though, you'd need to craft a Product Backlog from which the Scrum Team can extract backlog items that fit a central coherence. A Product Backlog that doesn't lend itself to unified Development Team ...


2

I am in similar situation with a team of DEV & TEST people. After several Sprints, we have agreed to have a norm for "Normal stories" that Dev/ Test effort ratio is ~ 2:1 (= current team structure with 6 DEV & 3 Test) We are not really converting Story Points to hours but we built a common sense to forecast Dev & Test effort based on ...


2

From a Scrum standpoint, there is no such thing as a senior scrum master. One could argue that it is a similar to a distinction like "senior" developer except that scrum has no space for hierarchy in scrum masters. From a practical standpoint, I've seen it mean 3 things. First, it's sometimes a vanity title, just to add rungs on the ladder to climb....


1

From my experience, setting interim goal of each user stories target date spread across the sprint duration helped. That would of course require each story to be well sized and individually testable. Coupled with continuous integration and delivery, it helped me a lot to overcome this problem while leading technical delivery team.


1

I think that nvoigt's answer is solid. I will add a few things. I see the Sprint Goal as a way for the Development Team to not need constant interaction with the Product Owner. Consider that the Sprint Goal is created during Sprint Planning as a collaboration between the Development Team and the Product Owner and helps to guide the selection of the Product ...


1

The idea seems to make sense, as you mention, there are different roles and tasks. But the management of a project is, in my opinion, more like a Case (see Case Management Modeling Notation (CMMN)) and not a Business Process in the standard definition of BPMN fixed activities, input, output, and gateways according to those outputs. Also, if you follow a ...


1

We faced this problem quite often on our team. We had two types of experts per your definition: One who knew the legacy details of the application a little too well who'd be called on to handle old production issues Domain expert: like the UX Design expertise you're alluding to. We had asked all such X-functional folks to track everything on the "...


1

How should a scrum master/scrum team handle a situation where they have assimilated a cross-functional "expert" from elsewhere in the company, at a supposed 100% utilisation, when there isn't 100% worth of work and the "expert" keeps receiving external requests, as would be expected in their position? The best approach I have seen is for ...


1

This is one of the areas where, in my opinion, Scrum falls short of addressing real-world problems. Although it's good for teams to pursue the goal of having its members become cross-functional, there are reasons why specialists or experts may be necessary to support the team. These are people who are not on the team on a full-time basis and may support ...


1

When to talk the problems we encountered during sprint, Sprint review or Sprint Retrospective? When it's more effective. Scrum (and agile) are not very prescriptive. That's one of the biggest challenges for people trying to shift into them. and that's good. Just requires experimentation. The same challenges can (and will) be raised at different forums, ...


1

In the Sprint Review, you show the customers (and everyone else that is interested) the product increment you have just completed. If during the sprint you encountered problems that caused you to deliver something else than what you lead them to believe (less functionality, different functionality, etc.), then it would be good to mention those problems as an ...


1

It's always wise to prepare for hosting a meeting with a planned itinery list of the things that need to be discussed in order of priority. These can be ticked off once discussed but also recorded what was said. Having an assistant or work partner present to write down what was said helps, or if you don't have an assistant / work partner available then it ...


1

Bogdan gave a good answer to the question but here's something else to think about. One of the problems you may encounter when working with a team new to Scrum is that they want to start by making sprints as long as possible "because we can't deliver anything useful in less than a month". Long sprints with an inexperienced team are counterproductive in my ...


1

Excellent question. This is one of the topics that result in highly opinionated discussions when really it is clearly defined in the Scrum Guide. The Sprint Goal is therefore an objective that needs to be achieved by the Team during the sprint through the implementation of part of the Product Backlog. The sprint backlog is a stream of work items picked from ...


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