How do we resolve new items being brought into the Sprint?

[Jodi-Ann Rowe]

A few developers are able to finish stories, tasks or bugs before its initial estimation. This is perhaps as a result of incorrect estimations or not enough information in the acceptance criteria of a given card. How must we 1st resolve this issue?

[Trudy Claspill]

Hello @Jodi-Ann Rowe 

If you want to block the developers from adding issues to the sprint, for a Company Managed project you can do that by revoking the Manage Sprints and Schedule Issues permissions for them in the Permission Scheme(s) assigned to the projects that contain the issues.

Addressing incorrect estimates or insufficient acceptance criteria would be something you should discuss during your Retrospectives. As a team you should be discussing why this is occurring and come up with plans for how you thing you can make that more accurate. Implement your plan, then discuss the results during your next retrospective.

[Jodi-Ann Rowe]

Hmm. Thanks @Trudy Claspill . I'm wanting to do the hard work and address this and revert my findings here. My next Retrospective is tomorrow. I will put my findings of the team engaging in this and seek how we may best we may resolve inaccurate estimations and insufficient acceptance criteria - if it is found that this is the case. I feel the dynamic of the team may require some evolution for this level of openness and I want to inspire it.

[Tinker Fadoua]

@Jodi-Ann Rowe 

I think the developers need to learn more about the Agile Methodology and also follow the rules. While a Story, bug, or a task are not in the active sprint yet they shouldn't invest their time working on them. No matter how easy or badly needed. It is the Product Owner and Scrummaster's call. Priorities can shift quickly then they should adhere to the rules.

Wishing you all the best,

Fadoua

[J R]

Update: Most of the team understands the need to become enrolled in Agile related training. In the midst of this, priorities have shifted, the development team was assigned a new Scrum Master and Product Owner and has since agreed to self organize to decide its next course of action. I don’t have much trust in the next steps above.

[Nic Brough -Adaptavist-]

This is more of a human problem than one you should be trying to fix with tech.  Blocking people from doing this is not the right approach, the right thing to do is get them to do their job properly.

You don't really want to stop people bringing new stuff into an active sprint.  You want to have them finish what is in the sprint before taking in new stuff, but it's fine to do it when you're in situations where you've got people who can't help finish the last couple of bits off, so they might as well pull in some more that they can.

[J R]

I love this perspective @Nic Brough -Adaptavist- ., Thank you. I now wonder about equipping the team to finish the Sprint before taking in new things.

Perhaps encouraging the team to  work on what's in the Sprint in peers as opposed to in silos. This may encourage a developer to assist another developer in the event that his items are done.

[Nic Brough -Adaptavist-]

Yep, the point of the board and the sprint is that it represents the work of a single (multi-functional) team, not a set of siloes.

When a team gets into a position where they've only got a couple of stories left that they committed to, they know that the people working on them are going to get them done and others in the team can't help, then you have a handful of team members with free time. 

It's up to the team what they do with that time - some people will

• do more backlog refinement, making the next round of sprint planning easier
• pick up another story and make a start on it and some teams will
  • insist that they only pick up stories they can make fit in the current sprint,
  • make a start on something that's going to go into the next sprint, so they won't actually bring it into the current one and then make it look like scope creep has made the sprint fail (close with open issues)
  • simply pick a small story they like the look of that might not ever make it to the top of the pile
  • and, if in doubt, ask the product owner and scrum master what they should take a swipe at