Add a new Story in current Sprint

Wouldn't it be better for that developer to help the team to finish its work-in-progress first, before bringing any new work into play? Shouldn't spare "capacity" be determined by the team?

Assuming team would finish its work in progress during the Sprint. As per Scrum guideline can the team member discuss with PO and get new Story during the Sprint.

Thanks,

Pradeep

In my experience, adding a new story in the current sprint has often been a bad idea. When adding stories to a sprint, we are making 2 assumptions:

1) all other team members will finish their WIP by the end of the sprint, and

2) You will be able to start and complete the added story by the end of the sprint.

The more assumptions you have, the more risky your approach is. So i would stick to the scenario where there is only one assumption, i.e. "the team will complete their WIP in the sprint" and spend my time making sure that the assumption becomes reality.

Pradeepkumar,

I am assuming that your question is whether the Development Team should consult with the PO regarding excess capacity and the possibility of bringing in an additional item into the sprint, and not an individual Development Team member, yes?

I have to agree with Ian, Fatuma and Timothy.

On my team, there's always enough to do without adding something new in the middle of the sprint. I just wonder when the day will finally come, that I don't have to keep reminding them about it.

If you are adding story (ies) in current sprint, how will you represent the sprint goal achievement, velocity and eventually planning for future sprints?

Is adding story(ies) going to be a routine? If yes again showcases lack of maturity of Scrum team in proper planning of resources, user stories and estimations with task for each story to target in achieving a sprint goal.

For a moment even if we don't look at what the scrum principles say, do you feel that practically what is being done will help in planning and achieving the goals that were defined?

I have a little different problem.   We are forced to do a conceptual plan and commit to that at the beginning of a release.   The sprints are predefined at the beginning of the release however, twice, we have committed to the stories in a sprint and found out that additional stories were required.  Because these had a higher priority than the stories we had already committed to they were pulled into the sprint we were currently working on.   Both of these situations arose because the appropriate analysis had not been done.   Once it was a developer who had found out that additional work was going to be required in order for a new function to work and once it was on all of us for not thinking about how data flowed into an integrated system.  

I have brought this position up to the rest of my team members and they look at me like I have a second head.   They are under the guise that because we agile we can do this.   To me it appears that we don't know enough about the stories to commit to them and everyone is not doing their due diligence prior to committing to the stories.  

Any thoughts on this?

If the team are "forced" into making a commitment they cannot meet, why do they believe they are working in an agile way?

This is a good discussion. My thoughts are few folds here:

1. Adding User Stories between Sprint is one way of Iteration Planning called as 'Commitment Driven Planning' (Source Mike Cohn book Chapter 14).
2. Adding  User Stories between Sprint comes when there is a High Priority Items come in picture due business priority changes (possible scenario in real world).
3. Adding  User Stories between Sprint should be an exception and not a habit.
4. Well in such cases, it is certainly legitimate to:
   1. Happy Scenario - Remove less priority stories from current Sprint Backlog ('To do' List) and pull a new story of size of similar size. 
   2. Ok Scenario - Remove less priority stories from current Sprint Backlog ('In-Progress' List) and pull a new story of size which can fit in remaining available time. Well this may have few additional work to rollback any code changes taken, but not impossible). Also this will impact final Sprint velocity, however will be understood by management and you'll gain browney points too for being agile).

More reference: (Ref. ebook - http://www.infoq.com/minibooks/kanbanscrum-minibook) 

In nut-shell, being Agile, we need to be mature to handle real time scenarios and remain open for 'Commitment Driven' planning and gain maximum business satisfaction. 

Thanks & Regards,

Arun Manglick, (AWS-ASA/Dev/ASOA, SAFe 4.0 Agilist, PMP, PMI-ACP, CSM, PRINCE2 Practitioner, MS-Project, CSSGB, ITIL V3, MCPD, MCTS)

Technical/Agile Project Manager/Delivery Manager/AWS Cloud, Node.JS, AI & Machine Learning Professional – Synechron Inc. 

Hi All,

The problem I have is not exactly an issue but I would still like to put it on this forum.

So, our sprint starts after keeping in mind the capacity shared by the development team. However, at times what happens that the PO comes back and asks if its possible to pick up another story, minor one (probably a 1 or max 2 pointer) only in the current sprint. The development team still has the authority to make the final call whether to say yes to the story or not depending on how much work they have in their hand, etc. 

However, at times I feel they are still reluctant to pick anything, be it minor or major during the sprint work. Even though the ideal situation says not to change the sprint after it has started, but I find it strange if for business purposes we cant accommodate a 1 pointer even when they have some time in hand. 

Please suggest.

How do you know they have time in hand? What does the team do for the rest of the Sprint?

I would add such 1-pointer as the lowest priority. If there is free time after doing what the team focused on during the sprint (sprint goal), that 1-point could be taken. If not - not.

Rhea,

What is the discussion among the Development Team members during their Daily Scrum?   Are they discussing potential excess capacity in the sprint?   Do they believe they are either on track or ahead of their sprint forecast, and the Sprint Goal is well within reach?

If these things are not being discussed, why does the PO feel that the team can take on additional work?   Ultimately, it is the team's decision whether to add to their sprint forecast without jeopardizing the Sprint Goal, and it is incumbent for the Scrum Master to protect the team from any "pushing" of work to the team that they are not comfortable with.

I have had teams work with a concept called a "stretch" story, which basically identifies 1 or more stories at the top of the backlog that may be brought in by the team if their capacity and sprint progress allows it to be safely accepted into the sprint.   Otherwise, those items remain as top priority for the next sprint.

Definitively a Development Team decision. A matter that could be discussed at Daily Scrum. So "developer [, ...] can he consult with Product Owner" is a no-go. If the whole team agrees there is a need for more Items the DT could invite the PO to identify the Items.

From my point of view lots of topics are right here.

- If the sprint is completed and there is some time left the Dev. Team should ask the PO which Story they can put into the Sprint. It is necessary that each additional Story is then part of the Sprint and has to be done until the end. 

- During the Sprint if not all stories are completed it is nearly the same. The Dev. Team has to ask the PO which Story they can put inside. The PO has to decide and the Team can not take anything what they want.

- In all cases the PO has to decide which Story should come next. If the Team take what the want to do it might be that they take something that is not longer important or with lower priority in comparison to something else. The PO can do this together with the Dev. Team.

I find myself once again agreeing with Timothy Baffa and his pointed Socratic questions.

If sticking to the Scrum Guide:

The development team (as a whole) may elect to add more to the sprint backlog from the ordered Product Backlog. An individual on the team should not, unless the team has decided the practice is ok (I advise against Individuals doing this, but attempting to be non-prescriptive and encouraging self organizing teams...)

The Product Owner provides the ordered Product Backlog.

If the Development Team does not feel they can complete the top item in the Product Backlog with the time remaining, the can negotiate with the PO to bring in lower ordered items.

Repeating what others have stated, Daily Scrum (or parking lot after Daily Scrum) can be a good place to discuss/address the use of extra capacity.

If you are seeking non-prescribed strategies and recommendations:

I recommend seeing if the free DT members can help swarm remaining existing Sprint Backlog items first. The existing work in the Sprint Backlog has already been committed for forecasted completion in the sprint.

If swarming is not an option, I recommend reviewing existing ”completed” work from the Sprint. If we are talking software, could the increment use more tests, automating tests, build tools that automate what you did in the sprint (if similar work will be repeated later), better documentation, something else that is an implementation detail in scope of the customer ask? Remember, only your PO will determine if that work is ordered high enough for future sprints (unless you work in the same area later and choose to do upkeep).

If the current deliverables need no additional attention, then I would engage to PO with the DT.

I generally also recommend pair programming to help others on the team learn and improve skills. Also, spending time experimenting with new tools could also be an option.

I generally do not recommend padding estimates for the sake of padding. Maybe the estimates the team is deriving are too high. There may be data to help understand what is happening in your team’s sprints.

If you find the extra capacity situation happens regularly, leverage your retrospectives to look into experimenting with your Sprint Planning to see if an opportunity exists to avoid this situation.

Simple answer is yes.



However, there are guidelines that must be followed before coming to that conclusion. In general, the following are example working guidelines have been agreed by my Scrum Teams:

1. The individual(s) should consult the Development to confirm confidence/progress towards achieving the Sprint Goal and no help is required on the selected PBIs for the Sprint to create a potentially releasable Increment

2. If no help is needed, the 3 amigos (plus any other disciple needed e.g. architect, UX, content designer etc) should consult the PO to confirm the next priority* and decide if the work can be done in the time remaining in the Sprint, if not, can the story be thinner sliced or is there another PBI that can be done 

*prioritization has been successfully achieved if the Product Backlog has assessed new features, technical debt, defects etc in the context of achieving the Product Vision

Having stretch goals is a good approach, if you are being active and proactive in continuously improving, the potential is there for a Development Team's velocity will increase; the desire to bring in more work into a Sprint is a positive sign

Let's remember:

- the Sprint Goal should not be compound (e.g. achieve X and Y and Z) and SMART, you should create one goal that aggregates the functionality but fits well/meaningful/taking us a step closer to achieving the vision

- Pair programming should be a decision made by the Development Team when it is applicable

- If more tests can be written, as Scrum Master I would be keen to know why they have not been done because this implies work has not been done. 

For further information about The Sprint Backlog Can’t Change During The Sprint can be found here: https://www.barryovereem.com/myth-2-the-sprint-backlog-cant-change-during-the-sprint/