Scrum Development Blog

Better teams make better products.

Archive for the ‘Scrum Questions’ Category

When is a requirement truly required?

Scrum Questions | Posted by The 3Back Team
Feb 12 2010

Choose

  1. The development team creates a spec.desirements requirements acceptance test
  2. The Product Owner says it is.
  3. The business asks for it.
  4. There is a test which actually requires it to be there and fails when it is not.

Comment: We often find ourselves lost in the desirements trying to find the real requirements for our system. Those things which seem required often end up being only desired. The word requirement has suffered more from confusion and misuse than just about any other word in the IT lexicon of development. What is a “nice to have” requirement? I mean really! I have close to 20 years of experience in the industry including training and writing requirements. Even with all of that experience the word still makes me a little crazy. I like the word desirement because of it’s contrast with requirement. When there is a test that makes it required with a pass/fail then it is a requirement, until then it’s just a a desirement.

So, a more interesting question is …. When is a requirement truly required?

When are you ready for sprint planning?

Scrum Questions | Posted by The 3Back Team
Feb 10 2010

Choose:

  1. The PO says go.ready set go sprint
  2. The Teams says they are ready.
  3. The SM has determined a time box for the sprint.
  4. The team and PO agree to a time box
  5. The PO understands and is prepared to talk about the stories

Comment: There are a number of things you should do before you can even begin planning.  The most important thing you can do is make sure that your Product Owner is prepared, and understands what the stories are about.  Remember that the Product Owner is a role here, so what we’re actually saying is that someone on the Team knows about each story; that is, each story has its own champion (Story Owner) who represents the Stakeholder’s needs/wants to the Team. This may require that the Product Owner (person) coordinates the

How do you fill a sprint?

Scrum Questions | Posted by The 3Back Team
Feb 08 2010
  1. You get past work experience. And calculate the amount of work the team can handlestory fill sprint epic too big
  2. Get estimates from the team and double the number they give you to determine work load.
  3. Meet with each individual and see how much work they can take on. Build a sprint plan from that information. Then gather everyone, show the sprint plan and kickoff the team sprint.
  4. Use the PO/SM powers to challenge the team to take big bites. Get as much loaded in the sprint as possible. The PO/SM can form a powerful pincer to overcome resistance.
  5. This is sprint planning.  You commit one story at a time. Make sure the team is committing to sharp definitions of done.

Comment: After a Story is committed to, the Team (with the PO in the lead) has the option to reprioritize the Story list, and the Team takes the next one to consider. Once again, the Team comes to the “doneness” Agreement and commits to adding the Story to the list of already-committed-to Stories. This process is repeated until the Sprint is “full” and the Sprint Plan is complete.

When is a story too large for a sprint?

Scrum Questions | Posted by The 3Back Team
Feb 03 2010
  1. too big for sprintIt is never too large for the sprint. The team must learn how to meet business expectations.
  2. The team cannot agree on which stories to work  on during the sprint
  3. The product owner has prioritized the story into sprint planning without any written definition of done
  4. When the team cannot agree on how to commit to the story
  5. Teams are inherently anxious; SM/PO must challenge the team and not accept no for an answer.
  6. Make the sprint bigger so the story fits.

Comment: The Team may not be able to commit to a story, or might noteven be able to agree on “done.” This makes the story in question is an epic, by definition, and the Team must decide what to do. Typical choices include committing to an Analysis Story to figure out what to do about the epic, or extracting a smaller story from the epic to do instead (putting the remainder back on the backlog), or skipping the story altogether and moving to the next one. Bottom line: We need a sense of movement to understand what the team can and cannot do. Biting off chunks of work that are too large obscures movement and makes throughput / velocity that much harder to understand. Use the team’s ability to commit to understand the work that the  story represents.

Should the team be allowed to drop the retrospective?

Scrum Questions | Posted by The 3Back Team
Feb 01 2010
  1. sad scrum teamsYes, It’s their process why not?
  2. No, explain to them and work through why the retrospective is so important.
  3. Maybe, if they are no longer a team then why continue with Scrum?
  4. Only do retrospectives once a quarter and build up a good list of things to change.
  5. Yes, the process will take care of itself we don’t need to watch it that closely. After all it’s common sense!

Comment: Of things to watch out for and not allow this is high on my  list.  It boils down to this rule: If the team is not doing a retrospective then they are not doing scrum. The retrospective is where the team takes formal ownership of their process. In these situations I crack shins, and kick knee caps and generally do what is necessary to ensure they continue doing a retrospective. Without that we often see teams fall into “it’s not my fault”  because “x” told me to. In some cases “x” is the process that no-one owns, imagine the process that gets created by someone who decides to own it but, does not do it themselves!.

Retrospective is an external constraint that must be demanded of the team. There are many ways to run a good retrospective, ScrumMaster rise to the challenge and support your team.

When should a sprint end?

Scrum Questions | Posted by The 3Back Team
Jan 29 2010
  1. We have consumed all the work we said we would in our sprint planning
  2. All of the work has been completed.
  3. Both the team and the product owner agree it should end.
  4. The amount of time specified for the sprint has run out

Comment: Set a time-box and stick to it. Failing to adhere to the time boxes for your sprint is a badusing time boxes is best practice habit. Without time-boxes we rapidly loose our sense of predictability and the amount of complexity we tackle in each bite drifts upward. Teams become fragmented and loose cohesion. This is a strong rule but, by no means an absolute. Be smart when you vary your timebox and you really need a disciplined experience well formed team to carry this off.

Should we extend Scrum?

Scrum Questions | Posted by The 3Back Team
Jan 25 2010
  1. change scrum extendSure, thats what agile/scrum is all about.
  2. Sure, you might wonder if you are making things harder to detect.
  3. No way !!!

Comment: The idea here is that there can be only one source for Scrum. I guess that depends on where you get your definition from and what you need. Should there be only one way to think about scrum? Probably not, although,  a rookie mistake is to modify without have deep applied practice and experience under your belt. Should there be one clean centering definition? I hope so. The 1st common mistake we see people make is modifying scrum without understanding it. They often confuse themselves and their organization. Advice: Refrain from thinking about extending scrum or modifying it. It needs very little and all we seem to do is over complicate things.