My Preferred Agile, Scrum, and XP Resources

Posted on June 4, 2012 by charlesbradley

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)
  2. Deemer, et al. “The Scrum Primer”
  3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
  4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
  5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
  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)
  7. Derby/Larsen’s _Agile Retrospectives_

XP (Extreme Programming)

  1. Jeffries’ “What is Extreme Programming?”
  2. Jeffries’ _Extreme Programming Installed_
  3. Koskela’s _Test Driven…_
  4. Martin’s _Clean Code_
  5. Feathers’ _Working Effectively With Legacy Code_
  6. “The Rules of Extreme Programming”
  7. Wiki entry on XP Practices

Agile/XP Testing

  1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
  2. Cripin’s “Using the Agile Testing Quadrants”
  3. Crispin/Gregory’s _Agile Testing_
  4. Crispin/House’s _Testing Extreme Programming_
  5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
  6. Osherove’s _The Art of Unit Testing_

User Stories (which originated in XP)

  1. My “User Story Basics” article and all of the links at the bottom of that article
  2. Cohn’s _User Stories Applied_
  3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
  4. Lawrence’s “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)
  2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
  3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)

Filed under: Organizational Change, Product Backlog, Product Backlog Grooming, Product Owner Tips, Release Planning, Scrum, Scrum Adoption, Scrum Strategies, ScrumMaster Tips, Sprint Backlog, Sprint Planning, Story Points, The Daily Scrum, The Retrospective, The Scrum Artifacts, The Sprint Review, The Sprint Time-boxes, User Stories | 6 Comments »

One Way to Handle Bugs and Production Support in Scrum

Posted on April 18, 2012 by charlesbradley

Dear ScrumCrazy readers,

I need your help. I’m working on a Scrum strategy for handling bugs and production support on a Scrum team. This is the first draft of the chart below. I already have a couple of changes I would like to make, so I’d appreciate it if anyone could provide feedback on the chart below. Just hit the “comment” button below or email me directly with your advice. Thanks!

The Scrum Guide doesn’t directly address how to incorporate production support and bugs into your Scrum implementation. As such, it is left up to the implementers to decide how to handle it. The strategy(chart) below is one I’ve developed as a result of coaching teams that are new to Scrum.

I hope you don’t need the chart. I’ll say it again. I hope you don’t need the chart below. I hope that you have so few bugs and productions support issues arise, that you don’t even really need to worry about classifying bugs or coming up with a technique to handle production support. But, for the teams that need some guidance on how to incorporate these issues into their Scrum implementation, see below for one way to approach it. I also feel compelled to say that if you find yourself needing this strategy/chart often, you probably have some serious root cause analysis and retrospecting to do on these occurrences.

Why I include “Bradley” in the name.

Please be sure and read the “Preface” section on the chart below. There is an 8.5 X 11 PDF download below the image.

It’s a little difficult to see here on WordPress, so you might want to view it on my web site.

The Bradley Bug Chart
Download (8.5 X 11 PDF):  http://www.scrumcrazy.com/file/view/ScrumBug8x5x11.pdf

So, what did ya think?  Just hit the “comment” button(or “Leave a Reply” form) below or email me directly with your advice.

Filed under: Bad Smells, Organizational Change, Product Backlog, Scrum, ScrumMaster Tips, Sprint Backlog, Sprint Planning, The Daily Scrum, The Retrospective, User Stories | Leave a Comment »

I Mostly Hate Software for Managing Scrum Teams

Posted on January 31, 2012 by charlesbradley

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.

Filed under: Bad Smells, Organizational Change, Product Backlog, Scrum, ScrumMaster Tips, Sprint Backlog, Sprint Planning, The Scrum Artifacts, Transparency | 4 Comments »

Tips for Effective Backlog Grooming – Part 2

Posted on June 8, 2011 by charlesbradley

Tips for Effective Backlog Grooming

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.

Tip #1: Try to never schedule backlog grooming during the first or last 20% of the Sprint.

During the first 20% of the Sprint, the team is just getting started on this Sprint’s work, so you’ll want to give them some room to get a good start. During the last 20% of the Sprint, the team is working hard to get closure on the current sprint items, so that’s not really an ideal time to do it either. That middle 60% of the sprint is a good time to do backlog grooming.

Tip #2: Treat the backlog grooming meeting just like the first part of the Sprint Planning Meeting

  • Often called “The”What” of the sprint planning meeting, this part of the meeting talks about what will be developed in the upcoming sprint.
    • The PO presents the backlog items (often User Stories), the team ask for clarifications, and then the items are estimated by the team.
      • The PO then might indicate that priorities will change based on the estimate. Good! That’s the kind of collaboration that’s supposed to occur!

Tip #3: Make sure the PO knows that, during all of this sprint’s backlog grooming sessions, they will be expected to present enough work to last about 1.25 sprints or so.

The reason for bringing this much work to the meeting is twofold:
1. Often times PBI’s will be de-prioritized based on feedback in the meeting, so you want enough work leftover that you’ll be ready to fill a sprint.
2. It’s a good practice anyway to have a couple of finely groomed PBI’s beyond what you’re working on in a Sprint in case someone frees up and needs more work.

The PO may need to collaborate with the team to know how much work 1.25 Sprints worth is, but it need not be a lengthy discussion — just a very rough guess. Hopefully your team has seen the PBI’s at a Release Planning meeting or in some other backlog grooming discussion meeting. If not, then the PO can discuss the new PBI with a team member or two(informal product backlog grooming) to get a feel for the very rough effort involved.

Tip #4: The backlog items should be fine grained and well understood by the PO for this meeting to work well. Try to have an initial set of acceptance tests defined before the meeting occurs.

When the PO brings a backlog item to the meeting, what you don’t want to hear is, “Ok, I don’t have a lot of details on this item, but I’ve got the basic gist(or first draft) of it.” What you would rather hear is this “I’ve worked on this item and I have informally collaborated with both the customers and the team on it. I have a really good idea of the details of the backlog item as well as the acceptance tests for the PBI. It’s fairly solid, and I think there’s enough information there to start work almost immediately!”

Even if the initial acceptance tests are high level, that is better than no acceptance tests at all. The more the PO and team focus on getting to good detailed acceptance tests, the better.

Tip#5: Make sure everyone understands that estimates are not final until a PBI has been accepted into a sprint.

Since the team is getting a preview of the PBI’s, don’t let the team stress out too much on the estimates. Let them know that a PBI’s estimate is not final until the PBI has been accepted into the sprint. If someone comes up with new information between the Sprint Preview and the Sprint Planning Meeting, they are free to bring it up and re-estimate the PBI. This brings us to the converse of this tip.

Tip #6: Make sure everyone understands that priorities are not final until a PBI has been accepted into a sprint.

The PO is free to change the priorities of the backlog between the Sprint Preview and Sprint Planning Meeting. This is ok. We welcome late change, remember? In practice, though, I’ve found big priority changes happen rarely between the backlog grooming and Sprint Planning meeting, maybe 10% of the time or less.

While it may be frustrating for PBI’s to change priority often, remember that this kind of information is something we want sooner rather than later.

Tip #7: Keep your eye on the goals of the meeting

One of the goals of the meeting is that, when it’s over, the team has a handful of PBI’s queued up and ready to roll into a Sprint. All major questions have been answered (or at least assigned to someone to answer), and the team feels confident and knowledgeable about the upcoming work. Of course, like everything, not every last detail will be known, but it’s not for a lack of trying. At the end of the meeting you might try asking this of the team: “Of all of the PBI’s that were presented, a) which ones would make you feel very uncomfortable if you had to start tomorrow?and b) which ones do you not feel confident at all in estimating?” If any of these kinds of risk are identified, assign someone to help mitigate that risk before the upcoming sprint. This brings us to our next tip(available in Part 3 of this blog series — or you can click on the link to the full article below).

Link to Full Article:

Tips For Effective Backlog Grooming

What your backlog grooming tips?  Post them in the comments.

Filed under: Product Backlog, Product Backlog Grooming, Product Owner Tips, Scrum, ScrumMaster Tips, Sprint Planning, The Sprint Time-boxes, User Stories | 1 Comment »

Sprint Tasking Tips: Sticky Note Strategies

Posted on May 19, 2011 by charlesbradley

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.

Filed under: Scrum, ScrumMaster Tips, Sprint Backlog, Sprint Planning | Leave a Comment »

Sprint Tasking Tips: Team tasking strategies

Posted on May 18, 2011 by charlesbradley

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.

Filed under: Scrum, ScrumMaster Tips, Sprint Backlog, Sprint Planning, Transparency | 1 Comment »

User Story Pattern: Micro Stories

Posted on May 12, 2011 by charlesbradley

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

Filed under: Product Owner Tips, Scrum, ScrumMaster Tips, Sprint Backlog, Sprint Planning, User Stories | Leave a Comment »

Sprint Tasking Tip: Don’t Give Up!

Posted on May 5, 2011 by charlesbradley

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

Filed under: Scrum, ScrumMaster Tips, Sprint Backlog, Sprint Planning | Leave a Comment »

Best Practice: Look to the Scrum Guide *First*

Posted on April 29, 2011 by charlesbradley

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.

Filed under: Bad Smells, Product Backlog, Product Backlog Grooming, Product Owner Tips, Scrum, ScrumMaster Tips, Sprint Backlog, Sprint Planning, The Daily Scrum, The Scrum Artifacts, The Sprint Review, The Sprint Time-boxes, Transparency | 10 Comments »

Sprint Tasking Tip: Strongly prefer more granular tasks

Posted on April 28, 2011 by charlesbradley

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.

Filed under: Product Backlog, Scrum, ScrumMaster Tips, Sprint Planning, Transparency | Leave a Comment »

Next Page »
Follow

Get every new post delivered to your Inbox.

Join 147 other followers

%d bloggers like this: