Scrumcrazy_header5.jpg
scrumcrazybtn.jpg

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.


This article can be found online at:http://www.scrumcrazy.com/Sprint+Tasking+Tips
Updated to reflect the 2013 Scrum Guide

Executive Summary:

In this article, I give some tips and background on what considerations might be useful when creating tasks in the Sprint Backlog. Specifically, I speak from the following angles:
  • Scrum Transparency
  • The Goals of good Sprint Tasking

I then give ~30 Sprint tasking tips, such as:
  • Prefer not using hours to estimate tasks
  • Prefer "right sizing" task to one day or less
  • Strongly prefer smaller and more granular tasks
  • Re-tasking mid-sprint is perfectly acceptable
  • Prefer only 3 task statuses: TO DO, IN PROGRESS, DONE
  • Put a trend line on your burndown chart

Note that the advice in this article is primarily intended for "Shu/Beginner" level teams. It's hard to describe what a "Shu" level team is, but I would describe it as a team where the majority of members have been doing Scrum for a year or less. Having said that, some of the tips can give new ideas even to experienced teams.

The Tao of Scrum - Transparency

The key thing we're looking for in our Sprint tasking is a transparent view of the development team's tasks to turn product backlog items into a releasable software feature. This transparent view is for *no one else's* benefit other than the development team.(with the possible exception of the Scrum Master to help identify and remove impediments). Sometimes the Product Owner will benefit from the sprint task transparency, but that is a side effect of sprint task transparency, not a goal. To drive this point home, if the Sprint Backlog is used to try and blame or hold individuals accountable, especially coming from those outside of the Scrum Team, all attempts at benefiting from the 'Tao of Scrum' will likely be lost. See Tip# 1 below for more details on that.

The Goals of the Tips

Well designed Sprint tasks should
  • Increase transparency to the Dev Team
    • Accurately depict what every Dev Team member is working on at any given time.
    • Increase the Dev Team's ability to inspect and adapt.
  • Increase Scrum Team efficiency
  • Identify and reduce bottlenecks
  • Identify and mitigate critical path risks
  • Clearly communicate the work plan for the Sprint
  • Have some easy way of being summed daily, in order to monitor Sprint progress (such as with a Sprint Burndown)
    • This should increase transparency to the Dev Team on realizing whether the team will need to add or remove Product Backlog Items before the end of the Sprint.

Some Preamble

In my tips articles, I try to describe highly effective ways to fulfill the Scrum framework. The Scrum framework intentionally leaves holes that are opportunities for teams to fulfill the framework in the way that is best for a particular team's circumstances. The Scrum Guide defines the Scrum framework, and my tips are in no way meant to define or re-define Scrum. My tips are based on my numerous Scrum coaching experiences, and I believe them to be consistent with the Scrum Guide.

Note 1: For the purposes of my tips, I'm assuming that a Scrum team is acting in good faith to maximize transparency when it comes to the Sprint Backlog. In practical terms, this means that the Dev Team uses some sort of physical or virtual Scrum board to manage/display their Sprint Backlog.
Note 2: I use the terms "Sprint task", "task", "Scrum task", interchangeably as synonyms. In other words, all of those terms mean the same thing in this article.

The Tips

Tip- a practice that is definitely worth consideration, but might only be good in a few or very specific contexts or team situations. To read more, see How I Classify Coaching Advice

Tip # 1: Create an environment where estimate honesty and accuracy is valued

  • 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. See how these kinds of traditional Project management techniques doom IT shops to failure.
    • no one is going to be held professionally accountable for task estimates. This causes "estimate apprehension"
    • when someone signs up or takes on a task, and they feel the task estimate is way off, that person can re-estimate the task.
    • when someone signs up or takes on a task, they should not feel personally married to said task. No matter what, no one person "owns" a task. The entire Dev Team as a whole owns all tasks, they they are "signed up for" or not.
    • unexpected things will happen that affect task estimates, and that no one is asking team members to be accurate predictors of the future. Let's leave that to the late night infomercial fortune tellers.
  • If you happen to be 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. Only let other Dev Team members estimate tasks.
    • Provide information to your fellow 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, even if that means a high estimate, or a high estimate that incorporates the uncertainty of the size of a task.
  • 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 one tip, you might as well skip all of the rest because your estimates will never get terribly accurate or effective.


Tip # 2: Prefer not using hours to estimate tasks.

I used to think that hours were a good estimation technique for tasks, but I don't think so any more. They bring with them too much waterfall baggage like the 100% time utilization fallacy, thinking that tracking estimates/actuals is a good practice, and giving more attention to task estimation and "folliwing a plan" when we should be focusing on responding to change, and completing PBIs(potentially releasable software!)


Only the most advanced Scrum teams can excel by using something other than hours to estimate tasks. See User Story Pattern - Micro Stories


Tip # 3: Prefer using tasks that are "right sized" to one day or less.

(Remember that this article is targeted at Shu level Scrum teams, with Shu level as defined above) An easy and effective way that I've found to start off a team with Sprint tasking is to create tasks that are considered to be one day or less. This way, any task you can think of only really needs further attention if it's likely to be more than one day of work. If a task is more than one day, then I recommend breaking it down into 1 day or less tasks if possible. If that just doesn't seem possible because you don't know enough about it in Sprint Planning, then record the number of days you think it will be, so that the estimate can be used to sum the remaining work daily on a Sprint burndown or similar mechanism. Once someone gets into those larger tasks for a few hours, encourage that person to then break it down, just in time, into tasks of one day or less.

"Right sizing" is a technique used to fashion smaller chunks of work such that they are of similar size. Some people claim that "right sizing" is not "estimating." I think that's a silly notion. Right sizing is simply another "technique" for estimating. I mean, at some point, someone has to consciously think "this is one day or less" in order to "right size." That thought is still a form of estimating.

The Scrum Guide has the following to say in support of tasks that are one day or less:
  • "Work planned for the first days of the Sprint by the Development Team is decomposed...to units of one day or
less"
  • "The Development Team...often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work."
  • "The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum."



Tip # 4: Strongly prefer smaller tasks


Make lots of tasks, and make them small, even much less than 1 day. Smaller tasks reduce bottlenecks, increase transparency, and generally allow teams to optimize efficiency and productivity better, as we'll see in the other tips.

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 below verbatim!*
For the sake of transparency and many reasons that will become apparent below, small, granular tasks are good. By small, we mean preferring tasks that are 1 day or less per person involved in the hopefully small, atomic, and discrete task(See Tip #3 above). 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 waterfall 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 a lightweight 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 Sprint length, and usually not more than 2 weeks or so.
  • 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. This sort of just in time planinng minimizes plan changes and minimizes the waste caused by such changes.
  • 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 a more accurate sum of work remaining (aka The Sprint Burndown)
  • More granular tasks leads to a better comparison against a burndown trend line. Seeing this comparison of the remaining work to the trend line helps us understand if we'll achieve our sprint forecast or not.

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.


Tip # 5: 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 Scrum Master 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 lower end of the 3-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(refining) 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 programmer and 1 tester over 2 programmers.
    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(rightsizing) 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.


Tip # 6: Realize that "one day" of work is really like 5 or 6 productive hours per day.

The other 2 to 3 hours a day is time spent doing things other than working on the PBI's. Reading company emails, briefly helping others, interruptions, going to the bathroom, going to generic meetings (i.e. ones that aren't really focused on your backlog ) and taking breaks, are all examples of stuff that we generally need not track on the Scrum board. Having said all of that, working on bugs or production support might need tracking -- see the Bradley Bug Chart for that.


Tip # 7: Estimate effort, not duration.

Effort is the time someone on your team has to spend completing the task. Think of it is every time you work on that task, you start a stopwatch. When you stop working on it, stop the stopwatch and record the elapsed time. Repeat this until the task is done. Sum up the elapsed times, and that's effort. Now, don't actually use a stopwatch or anything like, just imagine that you're doing this in order to understand the concept of "effort" vs. "duration"!

If something has to be done by someone on another team, then that effort is not included in estimates, but might be worth a "zero" task. See Tip #26 regarding "external dependencies."


Tip # 8: Make your tasks as "atomic" as possible.

By atomic, what I mean here is:
  • As granular/small as the task can get without going below one hour(i.e. hard to split any further, like an atom!), AND
  • Done by one person (or a pair if you're pairing)

A task should generally be designed for one person (or a pair if you're pairing), with one exception. For tasks where a meeting/collaboration/conversation of some sort is involved, it's ok if the task is designed for more than one person.

Why?
  • Tasks that are not fairly atomic can create bottlenecks.
    • If single task really could be broken into 3 parts, where part 3 depends on part 1 and part 2, but part 1 and part 2 can be done in parallel with each other, you've just created a potential bottleneck. Split those tasks out so you can parallelize your efforts and avoid the bottlenecks.
    • If the task is defined for one person, but not granular enough, the task can create a bottleneck if the person that was working on it is all the sudden unavailable(sick, stuck in a meeting, at lunch, works different hours, etc). If you could have split that task into two or more parts to begin with, then it's much less likely the person will create one of these bottlenecks.
  • Tasks that are not fairly atomic decrease transparency. If three people have to touch the task before it's "done," how do you ever know who is working on it? Ok, maybe you have an answer for that, but how do you ever know if it's blocked at person 1 or person 2? If it really depends on 3 people touching it, doesn't that increase the chances of it staying in progress for more than 1 day?


Tip # 9: Try to make tasks such that they will not stay in progress more than 2 days or so.

Tasks like these decrease transparency. It's tempting, especially when depending on someone or some department , to create a task that will be some sort of ongoing thing that can span several days. Instead, try to break the task into one or more tasks that involve checkpoints of some sort. For instance, a task like "coordinate training with team Y" might end up spanning several days. First of all, you only need to estimate the amount of effort that YOUR team will be expending on that effort. Secondly, try to create milestones like "Meet with trainers to figure out deliverables", "deliverable part one", "deliverable part two", "training session."

Don't be afraid if your tasks end up being all wrong -- you can change them at any time during the Sprint.


Tip # 10: Try to estimate/right size 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 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(or right sizing). I then encourage the team to spend a short amount of time tweaking the tasks. 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 # 11: 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 Sprint Backlog or 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 # 12: 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.


Tip # 13: Estimate for the "mythical average developer"

Remember that, in Scrum when we say "developer", we mean anyone who helps turn PBI's into software, so it includes people with tradition roles like Testing, QA, programming, business analysis, architecture, etc.

I recommend estimating for the "mythical average skilled developer" on your team. This requires some imagination, but you should probably not assume who will be completing the task. As such, use your imagination to imagine the "average skilled" person on your team who is likely to work on the task. Obviously, if someone is highly unlikely to work on a task, there is no reason to take them into account when estimating. Whatever you do, don't overthink task estimates! Just task out quickly and then retrospect on it later.


Tip # 14: Defer task assignment

Try not to ever assume who will be working on a task. Further, don't assign out every task during Sprint Planning. Instead, let people sign up for tasks just in time during the sprint. This helps reduce bottlenecks and critical pathing issues. Having said that, it's a good habit to have everyone at the Sprint Planning meeting sign up for the their first task of the Sprint at the end of Sprint Planning.


Tip # 15: Prefer only 3 task statuses: TO DO, IN PROGRESS, DONE

Keep it simple. If you follow the other advice in this article, this is all the categories you will probably ever need. Other statuses on Scrum boards tend to create bottlenecks and decrease transparency. If your tasks are small like they're supposed to be, then status transitions are not really important. A lot of teams feel the need to put a task status/column for testing, but I think this is a mistake too. If you do this, chances are you're also tempted to use the same task card for the programming portion as for the test portion -- moving the task between these statuses. I think this is a mistake, because once again, it decreases transparency. Further, by moving it to some sort of "in test" status, the task will appear to be in progress when it may not actually be in progress at all. Just create a separate task(s) for programming, a separate task(s) for test, and separate tasks for other necessary pieces, and move on with life. Let us return to the original statement. Keep it simple. TO DO, IN PROGRESS, DONE!


Tip # 16: Don't ever track actuals

Scrum is a team effort, and tracking actuals makes it an individual showdown. No... seriously... Scrum is a team effort. Scrum is called "Scrum" for a reason, people! It's meant to convey the "all working together to move the ball down the field metaphor." Don't screw that up by tracking actuals. If you feel like you need to know whether you're ahead of schedule or behind schedule, we can do that with a burndown chart. If you feel like you need to convey the urgency of getting stuff done, we can do that with a burndown chart by drawing a trend line -- see the related tip.

It is perfectly acceptable for the team to retrospect on how long a Sprint task or Product Backlog Item took in the Sprint Retrospective. See the related tip#30.


Tip # 17: Restrospect, Inspect, and Adapt your tasks

As in all things Scrum, restrospect on your tasking abilities. Retrospect on the Sprint Backlog and the Sprint Burndown from several angles. Ask questions like:
  • What did the Burndown tell us this sprint?
    • Did we use what it told us?
  • Do we like the way we tasked certain tasks out?
    • If so, how can we make that better next time?
  • Were our task estimates pretty accurate?
    • If not, then how can we make that better next time?
    • Are there tasks that seem to be largely unpredictable in terms of estimates? How do we account for that?
  • Do our tasks increase or decrease transparency?
    • If they decreased transparency, how can we make that better next time?
  • Did our tasks fulfill the goals of well designed tasks? (See "Goals of the Tips" above)


Tip # 18: Prefer using a burndown chart

Sometimes you can get a good feel for how a Sprint is going just by looking at the board itself. It really kind of depends on how you organize your board, but a burn down is a more transparent and more accurate picture of how much work remains in the sprint. Analyzing the burndown can highlight several different types of challenges. Also, the Scrum Guide requires that you track the amount of remaining work daily, so a burndown is a good way to fulfill that required practice. I'd say it's the best way in most circumstances.

Tip # 19: Strongly prefer putting a trend line on your burndown chart

Sometimes called an "ideal line", put a trend line on your burndown chart that represents the team's progress toward the plan they created in Sprint Planning.

1. Plot a point at the beginning of your Sprint on your Sprint burndown (generally the Y axis) that represents the amount of work planned for the sprint during Sprint Planning. If you're "right sizing" your tasks to one day, then this just means counting the number of tasks.
2. Plot another point along the X-axis(days remaining) for the end of your sprint. When the days remaining is 0, put a point on the X-axis.
3. In a color other than the one you use to draw your real/actual burndown line, draw a straight line between those two points. This is your "trend line."
4. Note that this strategy only works well if you plan the vast majority of your Sprint during Sprint Planning, which most teams do.

The trend line can tell us several things.

  • In the early to middle part of the Sprint, if the capacity line is within about 30% of the actual burndown line, then generally no real discussion is needed. This is common as the actual burndown rarely is a perfect straight line because we live in an unperfect world.
  • In the middle or later part of the sprint, if the capacity line is moderately different (say > 20%) than the actual burndown, it generally points to a need for a quick discussion on the difference.
    • Sometimes you make changes, sometimes you don't.
      • The changes usually involve adding or removing Scope in collaboration with the Product Owner, especially if you're in the middle to latter part of the sprint.
      • The changes sometimes involve removing bottelenecks, but that is rare this late in the Sprint -- hopefully you've resolved any potential risks and bottlenecks during Product Backlog Grooming(Refinement), or earlier in the sprint.


Tip # 20: When to re-estimate tasks

The only time it's important to re-estimate tasks is when an estimate is off by more than one day or so. At that point if you're right sizing tasks to one day or less, then probably it's just time to re-task a bit. See Tip #11 for more info on that.


Tip # 21: Don't put PO tasks on the sprint backlog.

In Scrum, the Product Owner is not technically part of "The Development Team." As such, putting tasks on the Sprint Backlog that involve work to fulfill the Product Owner role (developing/detailing User Stories, researching business logic, meeting with stakeholders, etc) is not appropriate. If the Product Owner wants to put their tasks on a separate board, that is fine, but again... not on the main Sprint Backlog or Scrum board.


Tip # 22: Consider making tasks for all Scrum meetings except the Daily Scrum.

Scrum meetings take significant time, and since we're plotting our actual burndown against a trend line, go ahead and create tasks for those meetings if you want, estimating the length of time they will take. Don't forget, use person days, and multiply by the number of team members that will be present. If you don't find this useful, don't do it! Most teams I coach don't do this.


Tip # 23: Don't be afraid to create meetings and tasks for those meetings

Don't task yourself into meeting hell, but where the team believes a meeting or collaboration is warranted, create a task for one. This helps improve overall transparency as well as the ability to retrospect on meeting efficiency. I hope it goes without saying though, that not every person needs to be at every meeting, and not every meeting requires a task to be on the board.


Tip # 24: Strongly prefer sticky notes over software to manage tasks

  • Low tech is the best tech!
  • Managing tasks 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 # 25: Strongly prefer notating task signup on stickies

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


Tip # 26: 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 in a waterfallish way.


Tip # 27: Task status should always be updated immediately

Moving a task from TO DO to IN PROGRESS or from IN PROGRESS to DONE, or any other permutation thereof (sometimes tasks move backwards on the board), should be done within minutes of the time the person realizes the task needs to change statuses. This helps prevent duplication of efforts and it also greatly increases transparency and team coordination. An out of date board really confuses everyone.


Tip # 28: Strongly consider creating tasks for your retrospective action items


If you have action items from your previous retrospective(s), and you should or you're not doing retrospectives right, consider creating tasks on your Scrum board to accomplish those action items.
  • It is also generally considered to be a great practice to have your retro action items posted in a highly visible place so the team will remember them throughout the sprint.


Tip # 29: Consider a "Spike Task" for times when the it's really difficult to create tasks for a PBI


Sometimes a team will get to Sprint Planning and just have very little idea how to break down a PBI into workable chunks. This is usually a sign that they are not doing good Backlog Grooming(Refinement), but it does happen sometimes. It should be rare, so be sure and retrospect on it when it happens.

The answer: Do a "spike task" or tasks. Essentially, create a task to remove the uncertainty around what the tasks should be. They way I usually coach this, there is the "spike task" which has some sort of estimate , and there there is a "big bucket placeholder follow on task" which also has a rough estimate -- usually larger, but not always. Then, the purpose of the spike task is simply to remove the uncertainty. Once the spike task is complete, the person or people who completed can propose a set of "follow on tasks" to the Dev team, that will replace the placeholder tasks. The "follow on tasks" need not add up to the original estimate for the placeholder -- remember... we're Agile and transparent, so we're allowed to update estimates whenever there is material new information. Make sure that all of the tasks in this scenario are estimated so that you can "track the remaining work, daily"(burndown, etc) as per the Scrum Guide.


Tip # 30: Be sure to retrospect, inspect, and adapt!


Just like every other Scrum practice, it is absolutely imperative that your team inspects and adapts their practices. If you feel like your Sprint tasking is not being effective for your team, do a "Five Why's" analysis and read up on good tasking techniques.


Conclusion

I hope you have learned something from these tips. As always, I welcome feedback, both positive and negative! See the links to related articles below.

Related Articles


coaching(4).jpgForScrumMasters.jpgForProductOwners.jpgForScrumDevelopers.jpgPresentations.jpg