User Story Pattern: Micro Stories

Executive Summary

In this article, I describe a User Story pattern that is useful for teams that are advanced in their User Story practices. In short, the pattern is to ensure that all User Stories can be completed in 2-3 days by one developer. This pattern requires fairly advanced story slicing skills, as well as other key User Story skills and circumstances. However, when properly executed, the pattern has the follow valuable advantages for stories this small:

  • More opportunities to eliminate waste by deferring or dropping unneeded stories.
  • Less total effort required to understand stories.
  • Higher quality implementation: fewer bugs.
  • Less effort expended in creating and estimating tasks
  • Increased team morale by allowing more frequent story closure

In the article, I cover the team context that is required to achieve the pattern, the advantages of the pattern, and a strategy for progressing towards the pattern. I also discuss how this pattern can impact the Scrum implementation.

Link to full article: User Story Pattern – Micro Stories

Sprint Tasking Tip: Don’t Give Up!

Don’t give up!

I’ve coached several teams into self organizing to create a Sprint Backlog and task out all of their Product Backlog Items. The first couple of times is always painful.

Anecdote

One team I coached took 16 hours(X 6 people) in their first Sprint Planning Meeting for a 2 week sprint! (The Scrum Time-box for the planning meeting is 4 hours for a 2 week sprint.) That team had just about every challenge you can imagine.

  • None of the team members had ever worked together.
  • None of the team members had ever done Scrum before.
  • They were creating a Product Backlog from scratch.
    • In any new team I coach, I always give first attention to building up a nice backlog and recommend the Scrum transition not start until the backlog is beefed up. With this team, I didn’t have that opportunity.
  • They had a person who had never played the Product Owner role before and did not have a background in Product Management
    • He was a former developer…often the worst choice for a Product Owner
  • They had a person who had never played the ScrumMaster role before.

The one thing this team did have was me, an experienced Scrum Coach. I told them flat out, that due to the challenges, their first Sprint Planning Meeting would be the worst they’d ever experienced, but I promised them it would get better. The first thing we did in Sprint 1 was we created a task to represent the Sprint Planning Meeting and estimated it. The team estimated it at 3 hours. (!) Anyway, to make a long story short, we got more efficient. While I never advocate doing a detailed tracking of task “actual hours”, this one(the time for the planning meeting) I kept an eye on. Here is how it went:

  • Sprint 1: 16 hours
  • Sprint 2: 9 hours
  • Sprint 3: 3 hours
  • Sprint 4: 1.5 hours
    • Note that this is less than half the Scrum Guide Time-box for Sprint Planning.
      • Part of the reason this team could get this efficient is because they only had 5 developers, the low end of the 5-9 developer size for Scrum Teams.
      • There was also a significant increase in velocity between Sprints 3 and 4, so we were actually planning more work in far less time!

Two major things happened between about Sprint 2 and 3:

  • First, I finally caught the Product Owner up on his Product Backlog responsibilities. In Sprint 2, we began backlog grooming and built the product backlog up to a very healthy size. We also greatly improved the detail of each PBI, making sure we knew the acceptance criteria for each one.
  • Second, the development team became very proficient at tasking out their work(part 2 of the Sprint Planning Meeting). At first, the whole team sat around while one person wrote tasks. I let this occur for 2 sprints (it’s a good team learning experience, though somewhat painful). Then I strongly recommended they use my preferred practice, which is to scale the activity something like the following:
    1. Split the team up into pairs. If an odd number, make one a triplet. Try to mix disciplines. For instance, prefer 1 dev and 1 tester over 2 devs.
    2. Have each pair select a PBI to task out.
      • Optional: make a logical choice here, like someone who has the most knowledge about a particular PBI.
    3. Have each pair task out the selected PBI.
    4. Repeat steps 2-3 until until the team feels like they have enough work for about 1.2 sprints worth.
    5. Post all of the tasked out PBI’s for the entire team to see.
    6. Give the entire team a few minutes to tweak estimates and discuss. Time-box this step. For a 2 week sprint, about 10-15 minutes or maybe even less. Do not let estimate discussions drag on needlessly.

Have you ever experienced Sprint Tasking pain?  If so, click on the comment link and tell me about your experience.

As always, May the Sprint be with you!  🙂

Best Practice: Look to the Scrum Guide *First*

Short Story:

When teams struggle with Scrum, it is my strong opinion that they should look *first* to the Scrum Guide for guidance.
(Or *look back* to the Scrum Guide, if they are an experienced team)

Long story:

A more complete way of saying this is:
When teams struggle(whether they be beginner or experienced), it is my strong opinion that they should look *first* to the Scrum Guide, and secondarily to other resources (books, articles, online, other professionals) for help. In fact, read and learn as much as you can from the Scrum Guide and the secondary resources. So long as those other resources don’t contradict the Scrum Guide, then it’s probably ok to try what they suggest. If those other resources do contradict the Scrum Guide, then think long and hard before deviating.

I have observed the following Anti-Patterns with respect to Scrum implementation.

Faux Scrum: Disinformed or Misinformed
1. Someone advocates a practice that is not consistent with the Scrum Guide.
2. The team struggles with that “something, ” often times because the “something” is not really Scrum at all, but some practice that someone inaccurately said was Scrum.
3. Rinse and Repeat until either:
a) “Scrum” is a dirty word in your organization, or b) your organization settles for mediocrity, or c) you decide to move on to some other process, or d) until someone figures out what you are doing is way out of line with the Scrum Guide vision, and tries to help you get back to basics.

Faux Scrum: Give up quickly and Deviate from the Scrum Guide
1. A team struggles mildly with implementing some practice described in the Scrum Guide.
2. Rather than retrospect and improve their implementation of the practice as the Scrum Guide would suggest, they choose a different practice that deviates from the Scrum Guide, usually with negative consequences that that team may or may not have the ability to immediately see.
3. See step 3 above.

Faux Scrum: Pretend you’re doing Scrum
1. Pretend to be doing Scrum, but instead use a bunch of your existing practices instead of what the Scrum Guide suggests. “Hey look, Mom! We’re Agile!”
2. Rename a lot of your old practices, artifacts, and roles with Scrum terms. Proceed as usual with the status quo and tell everyone in your company how Agile or how Scrummy you are.
3. See step 3 above.
(Ken Schwaber calls this the “Methodology Facade Pattern”)

Faux Scrum: Selective Scrum
1. Like you did successfully with WaterRUP processes, selectively pick a small number of Scrum practices and implement those only.
2. Enjoy the new practices, but be sure you stop progressing towards the Scrum Guide vision either because you get too complacent or too busy.
3. see step 3 above

The Power of Positive Thinking
I know what you’re thinking. Man, this guy is negative! If you spoke to people in my personal or work life, I think they would tell you that I’m generally a very positive person. I’m even hilarious at times, but that’s hard to convey in prose about intellectual topics. I think, though, that they would also tell you I’m a very detailed person, and that I’m honest and direct about serious subjects.

So, rather than call everyone “Chickens” and “Scrumbuts” and “Faux Scrumites”, what I do instead is I advocate a positive strategy.
That positive strategy is : When deciding how to proceed with Scrum, look to the Scrum Guide *first*.

If you look at my blog and web site, I generally give positive advice, but I also don’t shy away from Worst Practices, Anti-Patterns, Bad Smells, and Traps. Any good tester tests happy, sad, and bad paths, usually with particular attention to the sad and bad paths. I do the same. I also make sure that I propose solutions to all of these Worst Practices, Anti-Patterns, Bad Smells, and Traps. I do want to help, but sometimes people are not Scrum knowledgeable enough to recognize the bad practices.

Sometimes, to convince people to get back to basics, I have to point out where they’ve deviated from the Scrum Guide. This usually involves quoting the Scrum Guide. Yet other times, to further convince people to get back to basics, I have to express some of the possible advantages and disadvantages of their current strategy. That’s part of being a Scrum Coach and change agent, and comes with a certain amount of resistance. I’m ok with that. The reason I’m ok with that resistance is that I do it because I passionately and honestly believe it’s the right thing to do.

Sprint Tasking Tip: Strongly prefer more granular tasks

This tip is just one of the roughly 30 tips that comes from my Sprint Tasking Tips article.

Two schools of thought: More updating or more granular

There are generally two main schools of thought about how to task out a sprint in hours. One thought is to create tasks that are a bit larger in size, but to re-estimate each task that is in progress at some point of every day, usually whenever the burndown is updated. The Scrum Guide is pretty specific on this — the task estimates must be updated daily so that the burndown reflects a very good estimate(to the team’s best knowledge) of the amount of work remaining in a sprint. In addition, according to the Scrum Guide, 1 day is the largest a task can be anyway.

Another school of thought is to make lots of tasks, and make them small, such that the need for the daily ritual to update each “in progress” task’s remaining time is really not necessary. Using this method, the burndown will still reflect very accurately the amount of work remaining in the sprint. For this strategy to work, though, the tasks need to be preferrably closer to a half day or less in size. I strongly prefer this method, because having to update each “in progress” task every day, especially when the tasks are larger, is a logistics nightmare and not terribly enjoyable(not to mention reminiscent of WaterRUP). Besides, smaller tasks reduce bottelnecks, increase transparency, and generally allow teams to optimize effiiciency better, as we’ll see below.

Granular is good!

*Development Managers, Project Managers and Team Leads: Don’t be afraid to be very detailed at the Sprint tasking level. Read this section verbatim!*
For the sake of transparency and many reasons that will become apparent below, granular tasks are good. By granular, we mean prefering tasks that are 1-4 hours of ideal time per person involved in the hopefully small, atomic, and discreet task. Many experienced Project Managers and Team Leads seem to fear this type of granularity. I think this fear is a holdover from traditional project management and WaterRUP techniques, and the use of planning tools like Microsoft Project. In traditional project management, making tasks too granular has disastrous consequences, and requires a huge amount of tedious maintenance to keep the project plan leveled and up to date. It doesn’t help that traditional projects would last for months or years, thus making granularity exponentially disastrous.

*But wait! Stop the presses! Take off those pukey colored “WaterRUP” glasses and let’s enjoy the Agile view for a minute.*

  • Agile processes like Scrum thrive on short cycles. The Sprint Backlog is the project plan for a single Sprint. Sprints in Scrum are limited to 4 weeks in length, and most teams choose a Sprint length of 2 weeks. Because of this, the Sprint Backlog’s project plan duration is literally *never* more than 4 weeks in length, and usually not more than 2 weeks in length.
  • The Sprint Backlog is never created in advance. That’s right, I said NEVER! You will almost never have to do any significantly sized re-working of the project plan because it is created just in time and your crystal ball only has to look 1-4 weeks into the future. So, the entire lifetime of this Sprint Backlog is never more than 4 weeks.
  • The Sprint Backlog is discarded after the Sprint. Yes, that’s right, I said discarded. You are never again chained to a project plan that never ends. You can literally tear up this project plan after 1-4 weeks!
  • More granular tasks leads to higher transparency, making it easy for you to know exactly what is going on within the team.
  • More granular tasks leads to a more accurate prediction of work remaining (aka The Sprint Burndown)
  • More granular tasks leads to a better comparison with the capacity burndown(aka “the ideal burndown line’). As such, timeline risks are almost immediately identified in real time!
  • Tasks are created and maintained by the self organizing development team, so no secretarial duties specifically for Project Manager types, like having to futz with MS Project or some other project data entry tool.

For the rest of the tips, I will assume that you’re going the more granular task route, but many of the concepts will translate to using larger tasks as well.

Link to full article:  Sprint Tasking Tips

What are your favorite Sprint Tasking Tips?  Post them in the comments.

Sprint Tasking Tip: Create an environment where estimate honesty and accuracy is valued

This tip is just one of the roughly 30 tips that comes from my Sprint Tasking Tips article.

  • Make it clear that
    • an estimate is not a commitment.
    • no one is going to be tracking actuals for each task and comparing them to estimates.
    • no one is going to be held professionally accountable for task estimates.
    • when someone signs up for a task, and they feel the task estimate is way off, that person can re-estimate the task.
    • unexpected things will happen that affect task estimates, and that no one is asking team members to be predictors of the future.
  • If you’re a person that does performance appraisals for those on your team,
    • Do the above under “Make it clear that…”
    • Try to rarely be the first person to give a task estimate
    • Try to never give an estimate. No seriously… try it.
    • Provide information to your team members that will help their estimate accuracy, but resist trying to strongly sway an estimate.
    • Encourage people to be as honest and accurate as they can.
  • Mention that task estimates may be a topic for retrospectives, but only so that the team will learn and get better at them over time.

If you don’t heed this tip, you might as well skip all of the rest because you’re estimates will never get terribly accurate.

Link to full article:  Sprint Tasking Tips

Over the coming days and from time to time, I’ll post a few of the tips individually, but I won’t pester you by sending out all of them any time soon.

As always, all feedback welcome.

May the Sprint Be With You!

Sprint Tasking Tips

Executive Summary:

In this article, I give some background on what considerations are most important when creating tasks in the Sprint Backlog. Specifically, I speak from the following angles:

  • Scrum Transparency
  • What the Scrum Guide Says
  • The Goals of Good Sprint Tasking

I then give 20+ Sprint tasking tips, such as:

  • Prefer ideal hours over real hours to estimate tasks
  • Strongly prefer more granular tasks
  • Re-tasking mid-sprint is perfectly acceptable
  • Prefer only 3 task statuses: TO DO, IN PROGRESS, DONE
  • Put a capacity line on your burndown chart

Link to full article:  Sprint Tasking Tips

Over the coming days and from time to time, I’ll post a few of the tips individually, but I won’t pester you by sending out all 20+ of them any time soon.

As always, all feedback welcome.

May the Sprint Be With You!

%d bloggers like this: