6
Embed Skills, Not Individual Roles
Ideally, all product development resources should be intrinsically part of the Scrum Team. That makes any team member developing the product a co-equal “Developer,” regardless of variant skill sets within the team.
A product-design focused Developer should be treated as an integral part of the Scrum Team, rather than a ...
5
Is this a standard or good practice in facilitating a retro to 'censor' known issues like this?
Yes and no. I feel it's wrong to censor anything, especially talking about impediments at a retrospective. On the other hand, discussing the whole issue again and again and again when nothing has changed is unproductive and wasteful.
As an example: in my old ...
4
I've used Scrum in a number of part-time teams and the truth is, nothing really changes - you just have a lower capacity so you plan less work into your sprints.
There are only two things I'd consider differently:
1) You have a quarter of the time so I'd expect the meetings to be a quarter of the time. In a 2 week sprint, instead of a 4 hour planning, I'd ...
3
In Scrum, the Definition of Done exists on two primary levels - the Product Backlog Item and the Increment. If you cannot satisfy the Definition of Done for a given Product Backlog Item or Increment, then the criteria should not yet be in the Definition of Done.
My suggestion is to allocate time to set up the foundations that you need to be able to get to ...
3
I am part of a majority remote team; and although not part-time, my last project involved a full team of matrixed employees with part-time availability for this project/team. I hope some of my experience will help as you work through the key questions you have listed.
Should we try to setup times for when everyone should work, or should we allow ...
3
I would recommend focusing on Agile principles over frameworks (Scrum in this case). GitLab is an entirely remote organisation and don't adopt any specific framework, and instead prioritise Agile principles above any specific framework.
If everyone who is working on the project is remote, Strict working hours and meetings/ceremonies will likely inhibit the ...
3
TL;DR
Right now, you're trying to synchronize your teams without first determining whether they're really one logical team, two independent teams, or multiple interdependent teams. In my professional opinion, you really need to solve for that before determining the best way to proceed. That makes this a potential X/Y problem, for which the solution is ...
3
As you suspect the standard purpose of the scrum review is to 'inspect the Increment and adapt the Product Backlog if needed'. In practice this means showing what work is now done (so these items can be removed from the backlog) but also to review that any changes in the market conditions & use cases of the product haven't caused a change in priority or ...
3
You need to review the product increment. From what I understand from your question, it seems to me that you are mostly reviewing the work that you did to build the actual increment.
If you want to track the work, acceptance testing or integration testing should be tasks associated with a User Story. You might also have a task for development, for code ...
3
This is not an unusual occurrence in Scrum.
We take into a sprint an amount of work that we believe we have the capacity to complete. However, we cannot predict the future and so there will be times when not all the work is finished by the end of the sprint.
There are many reasons for this, including:
Discovery occurs during the sprint and we realise that ...
3
The Scrum team alone cannot solve every impediment. It is a good idea to have some kind of escalation path for issues that are outside of the control of the team, but are recurring and damaging.
As a Scrum Master I would often look to escalate this kind of issue using a reporting process.
For example, I might produce a sprint report that says something ...
2
A retrospective should not ban topics. And a retrospective must not waste people's time, either.
With that said, what you could do is categorise the retrospective items according to different influence categories:
Items the team can change
Items the team can influence
Everything else / Items the team needs to accept
Once you have done that, the team ...
2
I think there are two answers to your question:
1) Different teams can absolutely have their sprint events at different times. There is no problem with this from a Scrum standpoint.
2) The challenge you are describing doesn't seem to make sense. If I know that my sprint ends on Thursday morning, I set to finish my work by then. There may be times that are ...
1
The Definition of Done is not something that you write once and then it is set in stone. Rather it should be a living document that you and the team review once in a while to see it it needs an update.
As a DoD should be used as a checklist, it is important that it doesn't have too many items that can't be checked off, because people will likely stop paying ...
1
It is obviously impractical that I say "halt everything and fix these", as we still have other things that need to be developed and delivered.
It is not unusual for teams that are new to Scrum and that are correctly applying the principles to get little or nothing 'done' in the first few sprints. This does not mean that the team achieved nothing, just that ...
1
No matter how hard we try such situations can come up at workplace, team cannot do all of the work planned. In other words team will be able to complete most/some of the work planned.
Discuss with Product/Business which all stories are urgent/important and use the Eisenhower Decision Matrix to bucket the stories. Now let Business/Product choose what they ...
1
If the same impediment is being raised Sprint after Sprint, that brings up a few questions.
Is someone actively working on resolving the impediment? Maybe it can't be resolved within the Scrum Team and maybe it can't be resolved in a Sprint, but what is being done to minimize its impact and ultimately resolve the underlying issues?
During Sprint Planning, ...
1
Censoring an impediment from the retrospective doesn't solve it. As it looks to be a major impediment that's blocking the team, maybe it's worthwhile to arrange a separate meeting to analyze the problem to get a shared understanding and find a way out of the impediment?
The advantages of planning a specific meeting are:
You can focus on the impediment and ...
Only top voted, non community-wiki answers of a minimum length are eligible
