Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A problem that I am facing and would like some input into is; a Product Owner introduces ungroomed (unfamiliar, not estimated) User Story(s) into the Sprint Planning meeting.

The issue that this has caused is the team rushes to understand and estimate the User Story(s), which puts significant time pressure on the commitment portion of the Sprint Planning meeting. The team also seems to be unsure of their estimate due to the rushed nature of grooming them in the Sprint Planning meeting. The end result of this is a rushed, half hearted Sprint commitment, which is usually an under-commitment due to so much uncertainty.

I have seen two distinctly different causes for the late introduction of the User Story(s):

  1. The team is new to Scrum and has been having difficulties grooming stories, prior to planning.
  2. A brand new high priority User Story has appeared just before the Sprint Planning meeting.

I have discussed these issues with the Product Owner and we have decided upon on actions, I am wondering what have you tried when the Product Owner introduces a brand new high priority User Story just before or even in the Sprint Planning meeting? What worked, what failed?

The team that is having difficulty grooming User Stories in new to Scrum; hence I suspect that some facilitation of their grooming sessions, mentoring and some time will help them.

Do you have any other suggestions for helping teams come up prompt Planning Poker estimates?

share|improve this question

migrated from stackoverflow.com Sep 15 '11 at 7:29

This question came from our site for professional and enthusiast programmers.

    
Since "experience" is the obvious answer (you provided it yourself), it seems silly to post anything else. What more could there possibly be -- other than -- experience? What kinds of magic are you looking for? –  S.Lott Sep 15 '11 at 9:52
    
You are correct Scott the second question I pretty much answered myself. I included the second scenario / question for completeness; as I really wanted to set the context of the question. I am most interested in answers (backed up with real experience) to my first question. Thank you for putting my post in the correct spot, I will use Stack Exchange from now on. –  Andrew Rusling Sep 15 '11 at 23:20
    
"answers... to my first question". Other than "get more experience"? I'm hard-pressed to think of any possible source of magic that can be thrown at a new team with a difficult situation. Think about it this way. If there was a magical solution to this, don't you think it would be the methodology du jour. No backlog, just last-minute sprint planning? The fact that no-lead-time-last-minute-sprint-planning is not the methodology du jour is a hint that this is essentially impossible to cope with. What are you looking for, realistically? Pragmatically? –  S.Lott Sep 16 '11 at 1:37
add comment

3 Answers

up vote 2 down vote accepted

Given they've just been given the story during planning (regardless of it being a new story or not having estimated it earlier) you have a few choices.

First, you can ask the product owner if the story can be left on the backlog so that it can be properly checked and estimated during this sprint, and take it next sprint.

If that's not possible, another option is to do it in a spike - a time-boxed story to investigate something or to try something out - and then you'll have a head start for doing it next sprint.

Finally, if you really must start on it this sprint, then try and find out as much as you can during planning, and take the story but make it clear of the risk that it may not be completed this sprint. If it doesn't get completed, so be it, you've done some of it and now know a lot more about it for the next sprint.

Remember, estimates are just the best estimates with the information you have at the time, and can be revised later when you have more info.

Also remember you should be spending about 5%-10% of the sprint in refining the backlog. Doing this really helps keep the planning meetings shorter, more focused and more productive.

share|improve this answer
add comment

Estimation is not something that should be done off-the-cuff or quickly and without thought, regardless of your methodology. I wouldn't expect the team to be able to quickly come up with a reasonable estimate without having an opportunity to look at the user story and think about it for a while. At the same time, I do recognize that there are high priority new features, bug fixes, or feature modifications that need to be addressed quickly so that the customer can see added value. It's a trade-off between delivering the feature now versus maintaining schedule and/or quality that needs to be discussed.

If this is a continual thing, that suggests a problem with the process. That doesn't mean the process doesn't work, but rather (in this case) the Product Owner doesn't understand the value in the process. The Product Owner and the rest of the Scrum team need to be able to work together. Continuously sacrificing schedule or quality doesn't bode well for the project. At some point, I believe that the ScrumMaster, on behalf of the team, needs to draw a line and simply put the story in the backlog for estimation at a later time and not include it in the sprint. It will just be at the top of the backlog for the next one. This will reduce stress and allow for greater quality.

share|improve this answer
add comment

A useful tool in this situation is Planning Poker. The team spends a few minutes asking the product owner questions about the story and then they each estimate the story points. The variety of estimates are used to probe for gaps. Using this tool over time, the PO will begin to realize what questions need to be answered before planning.

The Agile Project Manager (Scrum Master) should work closely with the Product Owner to develop appropriate sized clearly defined stories. The PM should protect the developers from having to estimate incomplete stories and developers should not commit to a story that is not achievable - ever.

share|improve this answer
    
The team is already using Planning Poker. We have found that Planning Poker works well for all of our teams if they have enough context around the User Story. To me a Scrum Master is a not a Project Manager, they are their to get the best out of the team and get all stakeholders collaborating in an effective way. The role of PM is split between the Product Owner, Team and Scrum Master. –  Andrew Rusling Sep 29 '11 at 22:20
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.