The Cutting Ledge

Whiteboards: Disasters Waiting to Happen

May 102012

Post-It Note Impression No. 14 (Photo credit: Kevin H.)

Should an organization use a physical visualization of workflow (such as a whiteboard and sticky notes) or an electronic one?

Personally, I prefer the physical ones. They tend to be way more visible, easier to have group discussions around, any changes are immediately visible as they occur, and physically moving those cards around releases endorphins.

There are decent reasons for electronic versions, though, especially if your team is distributed. Also, whiteboards don’t do cool automatic calculations and reporting. The main issue is that using an electronic tool can sometimes reduce actual interaction and collaboration, which is something tools should facilitate rather than replace.

Until recently, the best anti-whiteboard argument I’d heard was this:

I don’t like a physical whiteboard because I have to walk all the way over to it whenever I want to know something.

This came from someone who sat about twenty feet away. We’re still considering buying him a spyglass.

This was the reigning champion until I heard the objections, below. Individually, either objection is a solid contender, but when you consider they both came from the same person less than two minutes apart, they become the gold standard for anti-whiteboard objections. They are:

When people walk by the board too briskly, the sticky notes can come off.

And:

Sometimes, the cards are hard to move if they stick too much.

So, if your office is populated by world-class sprinters or chronic arthritics, you might consider an electronic solution.

Blaming Co-Workers More Effectively

Agile, Business Processes No Responses »

May 012012

Software Development Community Meeting (Photo credit: Michael Kappel)

At a recent conference, I attended a seminar on being agile. It was actually a seminar on Scrum, but using Agile as a label for Scrum is the big thing these days, I guess.

Anyway, the speaker told a story about how the daily standups revealed to a manager that one of the developers was making no real progress and, as a result, that developer was fired.

How many developers out there are all fired up about getting agile, now?

This calls to mind a time I was doing a presentation at the C-level for a company about agility, and I asked the question, “What’s the value in having the people actually doing the work telling you what the relative effort is?” and the immediate answer was, “So you can hold them accountable.”

Not, “Because that sizing will be more accurate coming from the trenches than management,” but because people could be more effectively and harshly disciplined.

I want to be clear that I am in no way about to say that team members should never be reassigned or even let go. Sometimes, as a last resort, those kinds of things have to happen for a business to keep moving forward. I will say this, though:

Part of being agile is recognizing that you are all members of the same team working on the same goals, and you will succeed or fail as a team.

If a person seems to be stuck on a task that doesn’t seem to be that hard, that person should feel safe saying, “I thought this was going to be easy, but it’s pretty complicated, and I need help,” or even, “My dog died, yesterday, so I apologize to the team, but the truth is that I didn’t get a lot done.”

On the other hand, the team itself has a responsibility to reach out to this person even if they aren’t forthcoming. If a co-worker seems to be working on the same thing all week and it was a fairly small backlog item, go to them. Say, “Hey, I noticed that your item seems to be sticking. Can I help you with it? Do you want to trade backlog items?”

Agility promotes transparency, and this can either be terrifying for your team or it can be edifying for your team.

The purpose of transparency isn’t to more effectively blame people; it’s to more effectively help people. It’s a recognition that, at some point, we will all be the weakest link. At some point, what we thought was easy turned out to be difficult. At some point, a highly-skilled professional will find themselves in the middle of a problem and have no idea how to solve it. At some point, a manager will completely de-rail the project. Transparency shines a light on these issues so we can work together to resolve them, not throw darts more accurately.

Does your team work this way? Do managers and developers realize that they are working together to accomplish a goal? Does everyone realize that accomplishing the goal is more important than doling out blame or punishment? Does everyone understand that working together to solve a problem is far more valuable to the business than accurately blaming someone?

The person telling the story about the underperforming co-worker getting fired held this up as an example of agile success. To me, it was a sign of dismal failure.

Agile and I Know It

Agile, Humorous (to me) No Responses »

Apr 252012

LMFAO at the Sunset Strip Music Festival 2009 (Photo credit: Wikipedia)

(Original song “Sexy and I Know It” by LMFAO)

Yeah, yeah
When I iterate
Managers be sayin, “Damn, that’s great!”
Velocity increase
With how often I release, yeah
This is how I roll
I got production in control
When you got a good WIP limit
No reason not to stay in it

Ahhhh – Girl look at that whiteboard
Ahhhh – Girl look at that whiteboard
Ahhhh – Girl look at that whiteboard
Ahhhh – I burn down

When I walk to the board (yeah)
This is what I see (ok)
Work items ranked
By priority
I got my workflow on the board
And I ain’t afraid to show it, show it, show it

I’m agile and I know it

Win Social Media in 7 Easy Steps

Hard Core Miscellany, Humorous (to me) 2 Responses »

Apr 102012

The content of tweets on Twitter, based on the data gathered by Pear Analytics in 2009. (Photo credit: Wikipedia)

This formula has been painstakingly compiled from months of observing how social media gurus are going about things, near as I can tell.

Step 1: Tweet Obvious Generality

@AwesomeSocialMediaExpert: If you want less turnover, make your employees happy to work there.

Step 2: Let some re-tweets roll in.

@SocialMediaGrill: So true! RT @AwesomeSocialMediaExpert: If you want less turnover, make your employees happy to work there.

@SocialMediaGorilla: Absolutely. RT @AwesomeSocialMediaExpert: If you want less turnover, make your employees happy to work there.

@SocialMediaGorillaGrill: Interesting! RT @AwesomeSocialMediaExpert: If you want less turnover, make your employees happy to work there.

Step 3: Blog about it.

@AwesomeSocialMediaExpert: Interesting article: The Best Kept Secret to Reducing Turnover http://chi.ty/chi.ty/bangbang

Step 4: Re-post blog link for the next week.

@AwesomeSocialMediaExpert: In case you missed it: The Best Kept Secret to Reducing Turnover http://chi.ty/chi.ty/bangbang

Step 5: Start LinkedIn group discussion around your blog. Do not actually discuss it.

(1) New Discussion in Big Business Coaches – The Best Kept Secret to Reducing Turnover http://chi.ty/chi.ty/bangbang

Step 6: Start discussion in multiple groups. Do not actually discuss it.

(1) New Discussion in Business Consultants – The Best Kept Secret to Reducing Turnover http://chi.ty/chi.ty/bangbang

(1) New Discussion in Better Business Consultants – The Best Kept Secret to Reducing Turnover http://chi.ty/chi.ty/bangbang

(1) New Discussion in Agile Platypus Fleecer Guild – The Best Kept Secret to Reducing Turnover http://chi.ty/chi.ty/bangbang

Step 7: Repeat.

@AwesomeSocialMediaExpert: Need to organize your presentations? Try using points!

The Project Costs You Always Miss

Business Processes No Responses »

Apr 042012

Idea Engineer (Photo credit: Wikipedia)

Company X sells products. Stop me if I’m going too fast, here.

In order to create a new revenue stream, Company X sells a membership which, when purchased, entitles you to a significant discount on the products.

As part of the effort to sell these memberships and renewals, Company X decides to show, on their website, the total amount of money your membership has saved you. The business value here is that a customer will see how much they’ve saved, compare it to the cost of the discount membership, and realize that it makes good economic sense to renew.

Now, imagine that, once this is done, the brass of Company X have a meeting and discuss the merits and demerits of also showing how much money you have saved for the current year along with showing a total figure. Eventually, this idea passes muster and is handed down to the developers to implement. Business as usual, right?

Two things have happened that make the ROI of this idea nearly impossible to track and may have already cost Company X a significant amount of money before this development even gets started.

First off, has Company X identified the actual business value of this idea? Maybe they have and, if so, they’re ahead of the game.

Many times, however, the business value of an idea isn’t quantified and, in some cases, isn’t even explicable. Sometimes, people ask for things because they have a generic gut feeling that it’s a cool idea, but nobody actually knows if anyone wants it or if it will help make money, save money, or protect money.

In the example above, it would have been helpful to ask how many more sales would be projected if this second figure (the yearly savings) were displayed along with the first (the total savings). Is someone really going to be pushed over the edge by that second figure? If their total savings didn’t motivate them to renew, will their yearly savings? How does the value of this idea compare against the value of the total savings idea? Is it a more valuable idea? Did we make a mistake, here?

This is why, in my user stories, I start out with a business reason. Why are we doing this feature? What is it supposed to get us? If you don’t know what the business value is of an idea, how can you make decisions about your ROI?

However, a second cost that is far more insidious is the cost of bringing that idea to the table. Let’s say the meeting to discuss that idea was an hour. I don’t know what the mean salary is of the people involved, but they were mostly VPs. Let’s say, just for kicks, the mean salary was $100 an hour. That means that it cost $500 just to introduce that feature to the backlog.

$500 bucks right out of the gates, not even counting the cost of developing it.

Is that a $500 idea? You can’t know if you don’t have some concept of the business value of the idea, but even if you do, I find that most organizations aren’t even asking the question: Is this idea worth the amount of money we’ll spend just to put it on the table?

I think it is entirely appropriate and good business sense to eliminate discussions about ideas that don’t have enough business value to justify the cost of discussing them. “Hey, Bob, that’s a cool idea, but it would cost us $1500 just to flesh that idea out, much less actually implement it, and it won’t bring in enough revenue.”

That sort of discussion does not happen very often, and it is all wasted money. Organizations often just assume that generating ideas, fleshing them out, and having meetings about them are just givens of how you do business. If you want to cut the cost of implementing an idea, you cut down operation costs (i.e. developer wages and/or development time).

This is the part of the equation that interests me, of course, as a developer. If you want to increase ROI, you can either raise the return or lower the investment. Most companies lower the investment by outsourcing (or hiring cheap contractors), keeping salaries down, unpaid overtime, and beating their developers with whips and short, artificial deadlines.

I very rarely hear of organizations lowering their investment by cutting the costs of idea generation, which is unfortunate, because if you only spend money on the Biggest Bang for the Buck ideas, and developers are only working on those ideas, and you are only releasing those ideas, I think you’d find that your operational costs are not what’s been holding you back.

Why I Am Self-Righteous

Hard Core Miscellany 3 Responses »

Mar 292012

Even Dexter Knows HTML (Photo credit: mollyeh11)

In a comment on my last post, Ciarán ÓNéill (and you all should check out his blog, by the way – smart dude) said I was being self-righteous. He was probably right about that.

In the early years of this century, I became a technical trainer for a local training company for web development classes. It was during this time that I really got plugged into the world of web standards and various patterns of thinking that I believe have served me well.

As time went on, I became very frustrated at the lack (at the time) of good HTML teaching materials. Most of them reflected barely any understanding of HTML at all, and many of them were rife with serious errors. I’ll never forget the day I saw a professional HTML course telling students they needed to put their H1 tags inside of P tags.

The ones that did not contain blatantly wrong information would often instill unhealthy ideas, such as HTML being defined primarily in terms of formatting. H1 wasn’t what you used to mark up first-level headings; it was what you used to make text big and bold. Even though CSS was on the rise, pedagogical tools had obviously not evolved in their understanding of the subject matter.

This came to a head when I began to teach the CIW Certification courseware and found it literally riddled with the kinds of things mentioned above, including such gems as defining XHTML as HTML documents that contained XML and every tag defined by its default visual representation in the browser. I sent a plain text file of errors in the very first course to the publishers, and that plain text file was 27k. At the time, they were making money hand over fist selling this stuff.

And I got mad.

I wasn’t mad because someone was “wrong.” Hell, I’m wrong on a regular basis. If I got angry every time someone said something wrong, I’d be hospitalized for high blood pressure and my blogs would take on an edgy tone of self-loathing because of my own propensity for error.

I was mad because someone claiming to be an authority in a subject was telling people the wrong things – and not just mistaken details here and there, but things that were wrong to the very core. Errors in understanding, not just implementation. And people who received this information didn’t know any better, and they would believe it and perpetuate it. The market would be saturated with these issues. “Wrong” would become “orthodoxy” and vice-versa. And as people know who tried to be standards-aware web developers in early 2000s, this is, in fact, exactly what happened.

Some of my blogs regarding my professional field are fueled by rage. When this happens, I’m often not very charitable to my hypothetical opponents. I won’t deny it. I’m a downright jerk about it most of the time.

But it’s not about someone being wrong and me being right. Who cares about that?

It’s that people who are self-proclaimed authorities are wrong and leading others in their wrongness.

I don’t get mad about the Scrum = Agile issue because random devs conflate the two. I get mad because “Agile Coaches” do it. I get mad because the Scrum Alliance does it. I get mad because I am staring down the barrels of a generation of PMs, consultants, and developers who will take Scrum as the new orthodoxy and any other agile methodology is some heretical pariah. I get mad because the would-be shepherds are leading the sheep to crappy pastures.

Paranoid? Maybe. Probably. But I have seen it happen before. And even if it doesn’t,it seems like I will always rail on people in authoritative positions (self-proclaimed or otherwise) who are going to lead others astray. I don’t think that personality characteristic will clear itself up anytime soon.

Back of this, of course, is that I’m accountable for the things I mentor or teach others about software development as well. I, like everyone else, have been wrong and passed my errors along. I wish someone would have told me at the time.

The Relationship of Scrum to Agile

Agile 4 Responses »

Mar 282012

A scrum (Photo credit: Wikipedia)

EDIT: Changed some language so as to not give the impression the Manifesto came before all Agile methodologies.

Before the wide adoption of Scrum, there were a group of very smart developer types who discussed values and principles that, if observed and implemented, would lead to delivering high-quality software more quickly than most approaches that were dominant at the time. These people created an Agile Manifesto and articulated the principles that drove it. It is this body of values and principles that is meant when we talk about being Agile, using Agile, etc.

It is important to note that those writings do not specify any specific practices, implementations, or methodologies. It basically says, “As long as you are pursuing these goals and relying on these principles to help you achieve those goals, that’s being Agile.” By and large, this defined itself over and against Waterfall – a process articulated by Winston W. Royce in 1970 as a hypothetical example of a flawed model that would not work for software development but inexplicably became the dominant model for software development and the undergirding of project management for software projects.

If you look at the Manifesto and the principles behind it, you will find nothing about time boxed iterations, sprint planning meetings, or anything that is a specific technique or methodology. Agile is something that is back of, transcends, and critiques methodologies.

This body of principles is reflected in people taking a crack at implementing these things in their software development. In fact, many of the things reflected in the Manifesto came out of some of these attempts. XP attempts to embody these principles. Lean / Kanban also does. Scrum also does.

That last bit bears repeating: Agile is a set of values and principles. Scrum is one particular methodology among others built around those values and principles.

For reasons that I suppose boil down to excellent marketing, it is both widespread and regrettable that Agile is used as a synonym for Scrum. Sometimes, this leads to very entertaining claims made by people who ought to know better such as Agile being invented seven years ago or “Agile projects always operate within a ‘Time-Box.’”

The cause has not been helped by the fact that when Microsoft uses the word “Agile” for their TFS templates, they inevitably mean “Scrum.” Even the Scrum Alliance shows what it really cares about by frequently using Agile as a synonym for their own methodology in their articles and materials (NOTE: This is borderline reprehensible, because they really do know better, which means this is deliberately deceptive in order to snag more Scrumbots who won’t know any better).

This isn’t just some pedantic issue.

For me, personally, one of the things I bring to the table is – as a developer, a mentor, and an instructor – a belief in Agile principles. I used to do this with Scrum. These days, it’s more the Lean / Kanban variety. Someday, it’ll probably be something totally different. But the principles will be pretty much the same; it’ll just be about finding more effective ways to implement those principles.

As a professional, it’s very annoying when people assume that everything I say or do or put on a profile regarding Agile is actually about Scrum. It’s very annoying to try to market myself to companies that say, “Oh, we tried Agile, and it didn’t work here,” when what they mean is they tried Scrum. This distinction becoming hazy in the marketplace has an economic impact on those of us who are very pro-Agile but do not practice Scrum trying to market our services and expertise to a world that no longer knows the difference and may have antipathies toward Scrum.

The other issue is that the equation of Scrum with Agile means a whole lot of ignoramuses are coming in under the Agile banner.

That is not to say that every Scrum advocate is an ignoramus. There are extremely intelligent people implementing, using, and coaching teams on Scrum and they are kicking butt. However, a phenomenon occurring in the marketplace today is that people learn Scrum and they become Agile Coaches, which is somewhat akin to me learning the recipe for clam chowder and going around telling restaurants the best way to make soup (which, invariably, is clam chowder). These people will comment and blog freely and often, filling the Information Superhighway with epistemological roadkill. They write articles. They give conference talks.

All these things reveal to anyone who knows better that these people have no clue, but this is the public face of Agile, now. Learning Scrum gave them a license to be Agile experts, so that’s how they see themselves, that’s how they market themselves, and that’s how the market encounters them. For every one Agile coach who knows what they’re doing, there are twenty who became Certified Scrum Masters, and their ability to sit in a room for two days has now given them Authority (I am a Certified Scrum Master, incidentally).

I feel bad for anyone who is a real Agile Coach trying to market themselves as an Agile Coach, because 90% of the time, Agile Coach is a nice way to say Clueless Scrum Master. And whenever I read a blog or hear a presentation or see an online discussion that is full of Agile fail, I know the person who wrote it is coming from the Scrum camp. The equivocation of Scrum and Agile has given them a license and a platform to address issues they do not fully understand, which has produced awesome advice such as some things I’ve seen in Agile Coaching blogs the past couple of months: “Don’t have too much interaction with the client because it interrupts the team,” “Make sure you’re updating the Scrum Master in your stand up and not the Product Owner,” and “Don’t use TDD on small projects.”

Any Scrum person who truly understands Agile probably cringes at those statements as much as I do, and that just proves there’s a problem.

Scrum may be Agile, but Agile is not Scrum. If you are going to claim to talk about being Agile, make sure you know the difference.

Field Guide to QA Testers

Business Processes, Humorous (to me), Tech Help No Responses »

Mar 132012

The actual first computer bug, a moth found tr...

Image via Wikipedia

DANGER! DANGER! DANGER! You’ve sent your stuff to QA for testing. What horrors will we find in the wild?

Chicken Little

Known Aliases: Teacup Storm, Spaz

Reported Bug: The e-commerce portion of the site is completely non-functional.

Actual Bug: Someone misspelled the word “shipping” in the second paragraph of the checkout page.

In the story, Chicken Little is a panicky creature who overreacts to very little data. Occasionally, this is also the case with a Chicken Little QA tester, but more often than not, this variety cannot tell the difference between “has an issue” and “unshippable.”

Every little flaw is a show stopper, and this overblown method of reporting defects often obscures what the actual defect is.

The Monarch

Known Aliases: Dalek

Reported Bug: The validation error messages should be a redder shade of red.

Actual Bug: There is no actual bug.

The Monarch loves the label “defect” instead of “bug,” because he believes that, if his personal opinions about the product aren’t met, this is the same as a defect. The Monarch loves to log defects about colors, verbiage, where buttons should go – things that have no bearing on whether or not the software is actually working or whether or not any business users / clients agree.

There is no reasoning with a Monarch, and if you ignore the “defect,” it will continue being logged in the hopes that you will eventually be worn down through sheer backlog attrition.

Yoda

Known Aliases: Mufasa, Movie Mentor

Reported Bug: Broken, a screen is.

Actual Bug: Who knows?

Yoda reports defects in aphorisms, riddles, and vague statements. If this were the real Yoda, he would do this out of a desire for your self-improvement. In the QA field, this happens for reasons that can only be described as mean-spirited.

Interacting with bug reports from a Yoda QA tester goes something like this:

Yoda: An error, the screen showed me.

You: What was the error?

Yoda: Remember the error, I do not. Screenshot it, I did not. Write it down, I did not. Trust your feelings.

You: Can you at least tell me what you were doing when the error occurred?

Yoda: Walk your own path, you must.

Working with a Yoda, ironically, leads to a very high incidence rate of turning to the Dark Side.

The Grand Architect

Known Aliases: Monty Haul, Horn o’ Plenty

Reported Bug: Users should get a confirmation email when they check out.

Actual Bug: There is no actual bug.

The Grand Architect cannot differentiate between unmet requirements and new functionality. To make matters worse, they have a seemingly infinite reservoir of new functionality to offer.

The Grand Architect is a very dangerous form of QA tester because many times, their ideas are good ones. The problem isn’t the ideas; the problem is that they get logged as defects to a feature rather than being considered new features that should be sized and prioritized along with everything else in the work log.

This often leads to features never actually making it to production as the development team works overtime to correct “defects” such as the failure to show an animated, spinning head shooting lasers out of its eyes whenever someone buys something.

Nessie

Known Aliases: Singing Frog, Art Bell Guest

Reported Bug: I swear this was broken a minute ago.

Actual Bug: Probably a mental one.

Nessie experiences bugs that cannot be verified by anyone else at any other time, including themselves. They can produce no evidence this bug ever occurred, but they are positive that it happened to them.

Nessies are tricky because, if they are correct, the problem is a circumstantial one that is difficult to track down but absolutely should be fixed. If they are incorrect, days can be wasted as the team attempts to trace what could possibly be causing this problem.

Good QA Testers

Known Aliases: Unicorn, Angela

Reported Bug: When I was on Screen X, I did the following sequence of actions, and it resulted in the following error. Please look at the enclosed screen shot. This happened Monday morning around 9:30 am. I consulted our business users, and they confirmed that this is an edge case that does happen, although it isn’t that common. We should fix it, but it might not be as high a priority as finishing the current feature the team is working on.

Actual Bug: Um, wow. Really? Um, yeah, I guess that is the actual bug.

Good QA testers are rare as hen’s teeth.

Part of this is the fault of developers. Testing practices among developers tend to be so poor that QA testers spend the vast majority of their time making the software just work. Hardly any time is dedicated to testing actual business exceptions, working with end users, coming up with possibilities for new features, assisting in prioritization, etc.

A Good QA Tester can reproduce her sequence of steps to test a feature. A Good QA Tester knows the difference between a requirement not being met and Everything Else She Might Think Of. A Good QA Tester is collaborating her findings with the business users and the people who prioritize the work log. A Good QA Tester is part of the development team, not a completely separate entity who exists outside the team’s boundaries. A Good QA Tester reports an error with as much detail as she can muster and provides as much evidence as possible.

A Good QA Tester has taken ownership of her position. She isn’t just someone who checks off steps of a script and yells when something doesn’t work. She is part of the team. She makes sure the business users are getting everything they asked for. She participates in generating ideas for improvement and helps them work into the team’s normal work flow. She discovers legitimate business exceptions that may not have come up in the original analysis and makes sure they are accounted for. She tries to break the system the way a user might. She can tell the difference between “likely” and “unlikely,” “important” and “unimportant,” and “actual problem” and “my preference.”

If you have the fortune of encountering a Good QA Tester in the wild, cherish the experience.

Relative Estimation Explained

Agile No Responses »

Mar 122012

Image via Wikipedia

Imagine, for a moment, that you own a Chihuahua.

I’ll give you a moment to come to peace with what your imaginary life has come to.

Now, let’s say you’re relatively sizing Dogs in Your Home. On a scale of 1 to 5 (1 being the smallest, 5 being the largest), what is your dog’s relative size?

Probably no one chose 5, unless you’re the victim of some science experiment gone awry, were shrunk down to a very tiny size, and after jumping on the keyboard to type out emails for help, you’re killing time by reading blogs about relative estimation.

Many of you probably chose 1 or 2, and you did so because you are comparing it to all possible dogs out there or possibly even all possible objects out there.

But from a relative sizing standpoint, the correct answer is that you can’t say. You can’t relatively size the dog because you don’t have anything else to size it against. At this point, it is the only dog in your home.

Now, let’s say you buy an Irish Wolfhound. Relatively size Dogs in Your Home, now, using the same scale.

Did you give the Chihuahua a 1 and the Wolfhound a 5? You probably should have, because in your set of items, the Chihuahua is the smallest and the Wolfhound is the largest. Keep in mind that the numbers do not tie to some objective unit of measurement – they are a way to size your dogs against each other, not against meters or pounds or how many of one dog you could fit inside the other dog.

Now, let’s say you buy a bus and name it “dog,” so that I have something bigger than an Irish Wolfhound in your set of items. What are your sizes, now?

Now we have a little room for debate. The Chihuahua is clearly the smallest, making it our 1. The bus is our biggest, making it our 5. Where you put the Irish Wolfhound sort of depends on how its size relates to the Chihuahua and the bus. It could be a 3, but we could also argue the dog isn’t really halfway between a Chihuahua and a bus, and we might make it a 2.

The important thing is that we’re not using some outside scale to dictate our sizes; we’re using the objects themselves to determine the scale. Whether we’re sizing dogs or planets, you have (relative to the other objects) small ones, big ones, and ones in the middle. In fact, the phrase “small planet” really only makes sense in comparison to other planets. In comparison to objective standards of measurement, even the smallest planet is pretty big, but that doesn’t matter for the purposes of relative sizing.

Let’s shift gears and talk about tasks.

I have to lift a paperclip, lift an empty soda can, and a full soda can. On a scale of 1 to 5, relatively size those against each other in terms of level of effort.

If you made them all 1, or 1s and 2s, you’re doing it wrong. You probably thought, “Well, all those are pretty easy, so they should all be 1s.” But remember, relative estimation doesn’t estimate things against some outside scale or against all possible tasks. You’re estimating the items relative to one another.

So, what’s the hardest on that list? Lifting the full soda can. That’s 5. The easiest? The paperclip. That’s 1. We can then have an enlightened discussion about whether or not lifting an empty soda can is closer to the effort required to lift a paperclip, a full can, or about in between.

This is how you relatively estimate tasks in your backlog. If you want to somehow tie these numbers to another scale (like days or hours), then track how long it takes you to complete a 1 or a 5, and there you go. But depending on your backlog, one team’s 5 might take two weeks, and another team’s 5 might take 2 days. And that’s exactly how it should be and how you get accurate time projections.

Thank you, and good night.

Great Moments in SWTOR

Hard Core Miscellany No Responses »

Mar 092012

Is there something wrong with the hologram, or is your face supposed to look like that?

- My operative to Grand Moff Kilran in a 4 man run of the Black Talon flashpoint

Towers should be towering. I approve.

- Vette on the roads of Dromund Kaas

I don’t think you know what the phrase “Straight from the horses mouth” refers.

It means: Coming from the highest authority.

If you heard it straight from the horses mouth then you should have quoted a Game Designer, George Lucas, or even possibly Yoda.

Also your post reads like you huffed some paint before typing it.

Edit: I guess if you were actually a horse and you used some sort of computer program that recognized horse language and typed it out here using that method -then it would also be "Straight from the Horses Mouth". Also if you spoke English as a horse that would work as well. If you typed it out using your hoofs then I am gonna say that you should change the title to Straight from the horses hooves.

- dmanlong in the SWTOR Operative forum

Older Entries