Sprint In Progress Tip – Resolve Obstacles and Update Task Completion Immediately! (Don’t wait until the Daily Scrum)

Intro

I have long recommended that Scrum teams have a team working agreement that their Scrum board (aka Sprint Backlog) be updated immediately, but at least once daily about 30 minutes before the Daily Scrum.

Someone once questioned me on this advice as follows:


If the team updates task and story state immediately upon a state change or does such updates at least 30 minutes before the daily meeting:

  • What is the purpose of the daily meeting?
  • What does the team talk about in the meeting?
  • In other words, doesn’t that make the daily meeting redundant and, therefore, waste?

My Answer

One should not assume that everything that needs communicating is communicated via the task stickies(or whatever task token your team uses). Therefore, while the tasks are spoken about at the Daily Scrum, they need not be moved in the daily standup, and their effect on the burndown has already been recorded and plotted.

Usually, they will say something akin to:
“Yesterday I finished (pointing) tasks A & B, and began working on task C this morning. I should be able to finish task C this morning, but then I have to partake in some interviews for a new team member, so I’ll need a new task later this afternoon. I’ll look at the board then to determine which task.”

“Yesterday I finished task F. I ran into an obstacle X working on that one [but rather than wait until today to report it in the daily Scrum…], so I hit up Bob and he said to talk to Lucy over in Finance, and they were able to get me past that obstacle. So, if you have obstacle X, talk to Bob or Lucy and they can get that fixed for ya, or come see me and I can help. I also started on task F at the end of the day yesterday, and I should have that finished after lunch. I’m thinking for my next task that I’ll look into Story 7 and pick up one of those tasks. I wasn’t here when Story 7 was last groomed, so a potential obstacle I might have is understanding some of the requirements. Who’s a good person to talk to?” (If the answer to this question is super short, then it’s handled immediately, if it becomes a deeper discussion, this issue gets resolved after the daily Scrum as an impediment/obstacle.)

“Hi team. I was out yesterday so I didn’t do anything, and I noticed by looking at our [accurate]burndown that we’re way behind schedule for this sprint, so I think we need to have a quick impediment meeting after the Daily Scrum and figure out what needs to drop or happen so that I can know what’s best for me to work on.”

Another example:
Let’s say your Daily Scrum is at 10am. Let’s say there are 3 tasks, task A, B, and C, that are dependent on each other. (I coach my teams to remove these dependencies and make tasks as independent as possible, but that’s not always possible or easily done). If Fred finishes task A at 11am today and then goes to lunch, why doesn’t he go ahead and move it? That way Jennifer could pick up task B, and get that done. Why should Fred wait until 10am tomorrow in the Daily Scrum to move his task, when someone could have begun work on it yesterday at 11am?

My advice

  • Move tasks and stories as soon as they change status, like immediately.
  • Have someone update the burndown shortly before the Daily Scrum, so that Scope(too much, too little) and critical pathing problems are apparent and can be identified as impediments in the Daily Scrum (to be resolved outside of the Daily Scrum)
  • Team members, attempt to resolve an obstacle on your own first.
  • If you can’t resolve it in what seems like a reasonable amount of time, talk to someone who you think can. If you’re not sure who to talk to, ask someone or ping the ScrumMaster. Do not wait until the Daily Scrum to do this.
  • Try to foresee and identify obstacles before they become obstacles. Give the team a head’s up if you see a likely obstacle coming. (Critical path issues are often easily foreseen)

Sprint Tasking Tips: Sticky Note Strategies

Tip: Defer task assignment

Try not to ever assume who will be working on a task. Further, don’t assign tasks to people in the Sprint Planning meeting. Instead, let people sign up for tasks just in time during the sprint. This helps reduce bottlenecks and critical pathing issues.


Tip: Strongly consider notating task signup on stickies

Most teams already do this anyway, but notating the person who is currently working the task greatly increases transparency.


Tip: Strongly prefer sticky notes over software to manage tasks

  • Low tech is the best tech!
  • Managing items at the granular task level is an extreme pain in the arse in a software tool. Strongly prefer stickies on a board!
  • Note for teams where members are not within 50 feet of each other:
    • If only a couple of your members are not within 50 feet, prefer sending a picture from a camera phone over making everyone use a software tool.
    • If many of your members are not within 50 feet, then you will probably have no other choice but to use a software tool. Prefer a very simple tool. Many of the Scrum management tools out there have a ginormous amount of bloat in them including many features that are not in line with the Scrum Guide.

Tip: Innovate with your task stickies

Some teams notate stickies by:

  • Adding a sticker to the sticky
  • Writing something or some symbol on the sticky
  • Using a different colored sticky

Don’t go overboard with this, but think about innovating your sticky system as follows:

  • Consider notating task stickies
    • that represent an external dependency (I usually use zero hour tasks for this)
    • that are on the “critical path”
    • that require “paired programming” or other required practices
    • for tasks that are “blocked”
  • Consider changing the way task stickies are arranged on the board
    • to illustrate task dependency
      • but also consider removing task dependencies if that’s easily accomplished
    • to illustrate the critical path
  • Consider using a different colored sticky for tasks
    • that represent an external dependency
    • that represent defects or bugs
  • Come up with your own way to innovate your task sticky system!

Again, don’t overdo it but do tune your sticky note system to your team’s needs. Also, be sure you’re not violating some principle of the Scrum Guide by notating your stickies.

Link to full article:  Sprint Tasking Tips

What are your favorite Sticky Note Strategies?  Post them in the comments.

Sprint Tasking Tips: Team tasking strategies

Tip: Try to estimate tasks as a team.

Don’t take this the wrong way. I’m *not* suggesting that you all sit around a table and estimate tasks like Planning Poker or anything. Besides, Planning Poker is for sizing Product Backlog Items, not Sprint tasks. What I am suggesting is that when your team does Sprint tasking, generally in the Sprint Planning Meeting, allow the entire team to see the tasks and suggest modifications. Typically, with an experienced team, I recommend the team split up into pairs to create tasks for each Product Backlog Item. I then have the team re-join later and let the entire team view all tasks and their estimates. I then encourage the team to spend a short amount of time tweaking the tasks and estimates. Don’t fall into task analysis paralysis or anything, just give some short amount of time for some high priority tweaking. Whatever you do, don’t overthink task estimates! Just put something down quickly and then retrospect on it later.


Tip: Re-tasking mid-sprint is perfectly acceptable

It is perfectly acceptable to re-task one or more tasks mid sprint. Sometimes, you’re just not able to accurately predict the tasks for your sprint. The most important thing about your Scrum board is that it accurately reflects the work remaining in the sprint, to the best of everyone’s knowledge. I recommend you do not re-task alone. The tasks were originally created as a team in the Sprint Planning Meeting, so it’s important that you don’t re-design tasks alone. Consult with at least one team member when you’re doing this. Also, inform whoever updates your Sprint burndown so that the calculations stay correct. If the re-tasking is noteworthy, take 30 seconds to increase transparency by letting the entire team know about the re-tasking activity at the Daily Scrum.


Tip: Make sure the Team fully understands all Tasks

Sometimes a small sub-portion of the Team will do the initial creation and estimation of tasks. In these cases, make sure that the Team eventually takes a broad view of the Sprint Backlog before finishing the Sprint Planning Meeting. Near the end of the meeting is a good time to have the entire team view the entire Sprint Backlog and get clarifications make tweaks. Don’t get too caught up in the clarifications, of course. Whatever you do, don’t overthink tasks! Just create simple tasks and then retrospect on them later.

Link to full article:  Sprint Tasking Tips

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

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: 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!

%d bloggers like this: