Should I use hours to estimate my tasks in Scrum?

My new recommended “starter” “complementary practice” for new Scrum teams is to simply create tasks and use the “number of tasks remaining” for a burndown.  (I also usually recommend that they try to make it such that the vast majority of their tasks are roughly 1 day or less) I encourage them more to focus on PRI (potentially releasable increments), Sprint Goals, and achieving a moderately consistent level of skill at meeting their Sprint forecasts (used to be called “Sprint commitment,” it’s been re-named in the Scrum Guide).  I also caution heavily against trying to achieve perfect forecast accuracy as that’s a fool’s errand in complex domains.

Using hours for tasks can lead down some really bad roads, most notably:  Former PM’s turned SM’s and other organizational members who try to apply PMI tactics (100% utilization, tracking actuals, etc) tactics to complex software development.  By preferring “sticking to the plan” over “responding to change”, they are completely violating Agile and Scrum.

This same bad road can also lead companies into think that “schedule/scope/cost” is an optimum model for software development.  As far as I’m concerned, schedule/scope/cost is a dead, failed model for software.

Now, using hours for tasks doesn’t have to lead down those bad roads — but in my experiences, they usually do.  Let’s not forget, Scrum used to require hours for task estimation, many years ago, but the Scrum experiences of the wider community over 20 years has spoken on the topic — hours is not always optimum.  I would go farther than that and say, at the Sprint task level, it’s usually NOT optimum.

Given the above, I’ll leave it as an exercise to others to describe where using task hours might not lead down those bad roads.

_____
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com

New Courses from ScrumCrazy.com:

• Scrum For Executives
• Agile Requirements: Product Owner and Team Collaboration Techniques
• Scrum Product Owner: Techniques for Success
• Evidence Based Management for Software Organizations(TM)
  • Class for Software Development Managers and Executives

If you’re interested in any of our classes, training, or coaching services, feel free to contact us.

Dealing with Hard to Find Bugs (Sprint Killers) in Scrum

This question was asked in an online forum(I’m paraphrasing):

> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress?  Like ones that take weeks to solve?

In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.

I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.

One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog.  Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs.  This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing.  The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.

The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software.  I would argue that this is not a sprint killer.  It is simply a fact of complex software development.

The real issue comes down to this:  Scrum transparency is trying to tell your team something.  What is it trying to tell your team?  What is your team going to do about it?

Related Articles

• The Tao of Scrum – Transparency

• One way to Handle Bugs and Production Support in Scrum

• One way to Handle mid-Sprint Scope Changes in Scrum

ScrumCrazy.com update:

• Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
• Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.  Feb 28th in the Denver Tech Center.  More info and sign up here!

My Preferred Agile, Scrum, and XP Resources

If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

My Preferred Resources

All are in order of my personal preference in each category.

---

Scrum

1. The Scrum Guide (Must read for all)
   • http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf
2. Deemer, et al. “The Scrum Primer”
   • http://www.scrumprimer.com/
3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
   • http://www.amazon.com/Agile-Product-Management-Scrum-Addison-Wesley/dp/0321605780
5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
   • http://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364
6. Kniberg’s _Scrum and XP From the Trenches_ (Note that there is a free PDF download of this book if you register with InfoQ – something I recommend anyway)
   • http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
7. Derby/Larsen’s _Agile Retrospectives_
   • http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649

---

XP (Extreme Programming)

1. Jeffries’ “What is Extreme Programming?”
   • http://xprogramming.com/book/whatisxp/
2. Jeffries’ _Extreme Programming Installed_
   • http://www.amazon.com/Extreme-Programming-Installed-Ron-Jeffries/dp/0201708426
3. Koskela’s _Test Driven…_
   • http://www.amazon.com/Test-Driven-Acceptance-Java-Developers/dp/1932394850
4. Martin’s _Clean Code_
   • http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
5. Feathers’ _Working Effectively With Legacy Code_
   • http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
6. “The Rules of Extreme Programming”
   • http://www.extremeprogramming.org/rules.html
7. Wiki entry on XP Practices
   • http://en.wikipedia.org/wiki/Extreme_programming_practices

---

Agile/XP Testing

1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
   • http://properosolutions.com/2011/10/the-secrets-of-successful-test-automation/
2. Cripin’s “Using the Agile Testing Quadrants”
   • http://lisacrispin.com/wordpress/2011/11/08/using-the-agile-testing-quadrants/
3. Crispin/Gregory’s _Agile Testing_
   • http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
4. Crispin/House’s _Testing Extreme Programming_
   • http://www.amazon.com/Testing-Extreme-Programming-Lisa-Crispin/dp/0321113551
5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
   • http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
6. Osherove’s _The Art of Unit Testing_
   • http://www.amazon.com/The-Art-Unit-Testing-Examples/dp/1933988274

---

User Stories (which originated in XP)

1. My “User Story Basics” article and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/User+Story+Basics
2. Cohn’s _User Stories Applied_
   • http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Lawrence’s “Patterns for Splitting User Stories”
   • http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

---

Special Agile Topics (if applicable)

1. Deemer’s “The Distributed Scrum Primer” (If some of all your team is remotely distributed)
   • http://www.goodagile.com/distributedscrumprimer/
2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/The+role+of+Managers+in+Scrum
3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)
   • http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961

Handling Scope Changes Mid-Sprint in Scrum

The first thing about handling scope changes mid-Sprint is to recognize what type of scope change it is.

Bug or Production Support request?

If it’s a bug, or a production support research request, then my preferred method is to use One way to handle Bugs and Production Support in Scrum . As it says in that article, I hope you don’t need that chart. If you’re one of those teams where such bugs and production support requests are very rare (say, on average, once or less every 2-3 months), I’d say just do it and you can choose whether to make it a Product Backlog Item or put it on the Sprint Backlog. You’ll probably lean towards PBI if it’s a big thing, or put it on the Sprint Backlog if it’s a small thing.

Scope Change to PBI in Progress

If it’s a scope change to a Product Backlog Item in progress, my hope is that this means a new or changed acceptance/story test of some sort. If you’re not practicing Acceptance Test Driven Design, you should be! For you non ATDD types, the old school terminology for this is a “requirement change.” I’ve been around the block a few times coaching Scrum Teams on this scenario. My best advice is this:

• If the change in scope is likely to increase the originally estimated size for the story by more than about 10%, then the change should be a new Product Backlog Item by itself. You may need the whole team to re-estimate the newly changed story.
• If it is less than about 10%, then just change your acceptance tests, do it alongside the current PBI, and move on with life.

Swapping in the new PBI

If the scope change does result in a new PBI, then in rare cases where it is strongly warranted, a Scrum Team should be flexible enough to swap that PBI in and do it in the current Sprint. However, this usually means some other PBI will have to be swapped out of the Sprint as well. If these kinds of “swaps” begin happening regularly, then your team needs to do a root cause analysis on the swaps in the Retrospective.

• In this scenario, don’t forget that the new, urgent PBI needs to be groomed, sized, and tasked out on the Sprint Backlog. Get all of your team together and you can usually do this in a matter of minutes.

Scrum Strategy – The Dev Team Improvement Backlog

The strategy I describe below is one I’ve used successfully in coaching Scrum teams. Your mileage may vary, of course.

Overview

• The Dev Team has a thing called the “Improvement Backlog”, where it keeps a list of things(Improvement Backlog Items — IBI’s) that are intended to improve the Dev team’s productivity.

Purpose

• The purpose of the strategy is to create a culture of self organization and “inspect and adapt” improvement within the Dev Team.
• The strategy also acts as a platform for allowing the Scrum Team to resolve technical debt, though technical debt is just one type of potential improvement. As an aside, bugs are not technical debt. Bugs should be handled differently. See more about technical debt under the “Considerations” heading below.
• This strategy is an implementation of the Improvement Community/Improvement Backlog concept that Mike Cohn talks about in Chapter 4 of Succeeding with Agile. More on that below under the “Other Notes.” heading.

Preconditions

• The Dev Team has enough flexibility from management and/or the Product Owner to carve out a small amount of time each sprint for productivity improvement. The rule of thumb I use is 10-20% of each sprint. If you have trouble convincing management, you might try asking management how much they know about the 7th habit of highly effective people.
• The Dev Team is not in the habit of creating new technical debt, testing debt, or process debt. You need to stop the bleeding before you can stay current and catch up. This strategy is about staying current and catching up, so don’t use it until your team has stopped the bleeding. For help with stopping the bleeding, have your Dev Team add “creates no new technical, testing, or process debt” to their Definition of Done(DoD) and work on that strategy first. If you already have a good DoD and your team faithfully adheres to it, you probably don’t need that statement.

Strategy

• The Dev Team has a thing called the “Improvement Backlog”, where it keeps a list of things(Improvement Backlog Items — IBI’s) that are intended to improve the Dev team’s productivity. (Note that I did not say velocity, as I do not believe velocity to be a direct measure of productivity, and I believe that software productivity can’t be directly measured). This backlog has many different things on it, and it is ordered by the Dev Team. The types of things are essentially anything that *might* have the chance to improve team productivity, while at the same time allowing the team to keep a sustainable pace. I say “might” because we want to create a culture where it is safe to experiment.
• Examples of IBI’s:
  • Team celebrations
  • Scrum process improvements
  • Technical Debt resolution
  • Bug Fixing (rare, but if it can improve Team productivity it’s ok)
  • Exploring new technologies
  • Attending Conferences/Training
• Each item is groomed, estimated^1, and ordered, just like PBI’s.Further, it’s best to break these down into smaller items that can be done incrementally, when possible. The Dev Team can use the retrospectives to feed and groom the IB, or any other time (formal or informal) to add to it. Like PBI’s, only the ones towards the top of the backlog are well groomed. The Dev Team can choose to invite the PO into the grooming activity if they so desire, but it is not required. The IB is ordered based on many factors, but the Dev Team is responsible for maximizing the productivity value of the IBI’s to the team and the wider organization.
  • ^1 These items should NEVER be estimated in story points, NOR counted in velocity, and these items should not end up on the Product Backlog. I prefer hours to estimate them, but any other unit (real or fake) can be used to do relative sizing of the items, so long as the unit is not confused with PBI’s, User Stories, or velocity — which are entirely different concepts.
  • These items should never represent code or testing around Product Backlog Items. If you need to improve the code or testing around the functionality of a PBI, then incorporate the “clean up as you go” time(also known as the Boy Scout Rule ) into your estimate for the product backlog item. IBI’s are specifically for things that are not directly related to PBI’s.
• How much time do we dedicate to the IBI’s each Sprint?
  This is entirely up to the Dev Team, but made visible to the PO and the wider organization. Making them visible on a team’s “Scrum board” is sufficient. These items can be planned in the Sprint Planning Meeting, or outside of it, but they should probably end up as part of the Sprint Backlog, just like PBI’s do. I find that the best way to dedicate the time is to negotiate with the PO on some number between ~10-20% of each Sprint. The Dev Team should let the PO influence that number, but not control it. Also, there may be circumstances where the team decides to use a much higher or lower % of the Sprint, but the team had better be darn sure that they can justify the outlier to the PO and wider organization.

Considerations

• In my opinion, this strategy is quite useful for almost all teams that meet the preconditions mentioned above.
• This strategy should never be used as a “dumping ground” for deferring work of any kind. See the precondition above about “no new debt.”
• Some teams execute this strategy by putting these items on the product backlog. I don’t like this for numerous reasons. The most important reason I don’t like it is because it incorrectly gives the PO authority over something that is clearly the domain of the self organizing Dev Team. The PO owns the “what features” part of Scrum, and the Dev Team owns the “how we deliver features” part of Scrum.
• I have found that this strategy is a huge morale booster to Development Teams and really increases the self organization aspect of the Dev Team.
• It is very difficult to measure productivity increases in software development, but anecdotally I have observed significant productivity improvements when this strategy is implemented.
• Resolving technical debt is a tricky thing. Most people define technical debt incorrectly, in my opinion. I essentially subscribe to Martin Fowler’s view of Technical Debt as a definition. It’s hard to predict the value of resolving technical debt, and many believe that you should never resolve technical debt unless it is directly related to a product backlog item being implemented. As such, I encourage teams to prioritize technical debt inline with any other items on the Improvement Backlog that could improve their productivity. This tends to lead towards fewer technical debt items being worked on, so it lowers the risk of doing non-valuable work. At the same time, it leaves open the possibility that the Dev Team really does believe that resolving technical debt is an improvement worth pursuing.

Other Notes

• I recommend that Dev Teams utilize this strategy *in addition to* the incremental cleanup strategies like the Boy Scout Rule.
• I’ve based this strategy on a couple of similar strategies:
  • http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate
    • More here: http://www.mountaingoatsoftware.com/system/asset/file/149/04-Iterating-Toward-Agility.pdf
      • In Cohn’s example, the Improvement Community(IC)/Improvement Backlog(IB) is centered around the goal of adopting Scrum, but he also makes the point that an IC can be focused on any group of individuals with any goal of improvement. In this case, our group is the Dev Team and our goal is Dev Team productivity improvement.
  • https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern-language/scrumming-the-scrum
• I justify this strategy by using some language in the Scrum Guide, most notably:
  • “No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;”

One Way to Handle Bugs and Production Support in Scrum

This article has been updated and republished here.

I Mostly Hate Software for Managing Scrum Teams

Update February, 2012: I’m currently seeking my next engagement as a Scrum Coach or ScrumMaster, so please contact me (You can use the “About” tab above) if you know of an opportunity.

I often get asked to evaluate a particular Scrum tool or to compare the relatively value of one to another. To be honest, tool evaluation is not something I spend significant time on. Most teams I coach have little choice about which tool to use, so I usually just a) try to encourage them to use more manual techniques and b) help the team adapt the tool usage to their optimum performance/usage, which sometimes means no usage.

I hate the tools

Ok, hate is a strong word, but I’m generally anti-tool when it comes to managing Scrum artifacts and data. I strongly prefer more manual techniques (Scrum Boards, sticky notes, story cards, white boards, wikis, etc).

Reason 1: Tools often hurt more than they help. (Decreases Productivity)

The vast majority of the time I have seen Scrum teams extensively using a tool, it is wasteful or aids in creating poor habits. It’s pretty hard to justify spending money on a tool that decreases overall productivity. I’m amazed at how many companies do this. I also believe that most of these tools have a huge amount of bloat in them, and thus the bloated features either a) obscure the needed features or b) waste a lot of time with very little ROI in terms of value.

Reason 2: They usually encourage bad habits, or at least enable bad habits. (Decreases Transparency & Productivity)

• Bad Habit # 1: The worst habit they encourage is that they often obscure transparency by hiding data inside the tool that has to be …started up, logged into, and menu driven to the point of wanted info. Transparency in Scrum is VERY important, which is why I favor more manual techniques. This obscurity is extremely widespread as it affects the product backlog and/or stories, sprint backlog tasking, teamwork, optimizing with a burndown chart or other sprint progress monitor, etc. Transparency aids in inspection and adaptation, so the converse is also true: obscurity detracts from inspection and adaptation and thus, detracts from the empirical nature of Scrum.
• Bad Habit # 2: They discourage mis-use of good techniques. For instance, in many tools, there is no direct support for story tests/acceptance tests directly with the User Stories themselves. One tool at least allows some basic html formatting and tables so that you could put in some concrete examples like those that are encouraged by the “Specification By Example” technique. However, that tool’s HTML formatting is very clunky and far inferior to any decent wiki.
• Bad Habit #3: Having a tool encourages double entry. I’ve seen teams where, because they were forced to use a tool but also wanted a good Scrum Board, had to do double entry of the same information. Giant waste of time.
• Bad Habit #4: A tool encourages mis-use of metrics created by Scrum related data such as velocity. Many managers and executive types will try to do draw incorrect conclusions from data tracked in such a tool. Yet another giant waste of time. The managers and executive types should instead be focusing on whether the users of the system are getting value out of the features that are being provided. While some management has a responsibility to focus on productivity in software development, micro-analyzing the Scrum data is not a good way to do this.

Reason 3: The development team usually has the tool forced upon them, or usually has no choice but to use a particular tool. (Decreases Self Organization)

Besides the normal effects of top down mandates (poor adoption, minimal ROI, etc), the elephant in the room created by mandating tools is that it greatly harms self organization on a Scrum team. Mandating particular tools or tool usage is just another form of command and control management. To achieve Scrum’s benefits, self organization is absolutely vital, which means, when it comes to tools, the team should be able to make their own choices.  I want the team as a whole (and preferably not the ScrumMaster at all) to create, maintain, own, love, and care for their own artifacts.  Having said all of this, it’s perfectly acceptable for management types to try and organize company strategy around goals and timelines — I just don’t believe that Scrum software tools are a good way to do that.

In Conclusion…

There, I said it… I’m generally anti-tool for Scrum artifacts and data.

In a future blog post, I intend to talk a little about some special contexts in which I think tool usage is ok, and about my general views as to the kinds of tools that I like. Teams where multiple members are working mostly remote is one exception to my generally anti-tool stance. I’ll talk more about that in the future post.

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.