Repetitive Tasks an Agile Smell?

Heard an interesting idea at Agile Coachs' Camp a couple weeks ago. Someone called it Value Points. It was a point system done by the Product Owner related to the relative value they saw in each Product Backlog item. This would be separate from the points the team would give an item based on complexity/effort to implement.

My thought is that this could be a nioce way to keep team pointing as an input measure while using the Value Pts as an output one. That is, "regular" story points would be used just to determine what the team could take in for a given Sprint. The Value Pts would be the output measure of business gain for the work performed.

However, I still think task burndowns can be useful and other burndowns could suffer from the same 90% problem. Story pt burndown can produce a stair-step result that may not help much either. And delivering test pts doesn't seem to me to necessarily translate to stories completed and value delivered either.

But on one of my larger coaching experiences, the teams decided to track tasks in the burndown, but all tracked stories by "Not Started," "Being Worked," "Blocked," and "Done." The "Blocked" category was one being worked but currently held up by some impediment. They also eventually came up with a color scheme on their wall where they tracked these just for visual impact from a distance.

Of course, the real "tracking" was the close daily communication they had in the team. between teams, with Product Owners and with management. Had they been more remote from one another, they'd have needed something more formal, but perhaps still along these lines.

I also think that task estimation in hours add little value in agile processes. In my opinion, given a story, you should only formally capture the tasks needed to implement it as a clarification mechanism, not as an estimation and sprint-tracking mechanism.

I shared my thoughts on this very same topic some time ago

"...we need to change the acceptance criteria from vague statements to verifiable examples..."

Your acceptance criteria consist of vague statements? Really?

Hmm.

"...estimate the complexity of each of the tests for a story. The team tracks the number of acceptance test points delivered."

Sounds like an extra layer of waste to me. I would ask: What are the constraints that prevent us from dispensing with estimation and measuring the working software delivered? I would want to remove or mitigate those constraints rather than adding workarounds like estimating the tests.

Furthermore, why are the tests complex enough that you would consider estimating them? Isn't that a smell in itself?

AFAIK Dan Rawsthorne came up with this idea, under the name Earned Business Value. Description is here: www.netobjectives.com/blogs/calculating-earned-...

I've used this on quite a few projects. It gets the PO engaged nicely, and provides useful information about the relative amount of business value delivered as of any given date. The PO can make decisions about whether to continue the project based on that info. In one case, I had a PO decide to stop a project early because he had received 80% of the value he wanted, and he thought it would be wiser to pay the team to move on to another project than to finish off the remaining "nice to have" backlog items. Sweet!

It's easy to chart the value points to show progress toward delivery of customer-defined value. It's a good metric.

But it's not the same thing as velocity or throughput. It's not a substitute for tracking the working software delivered. It's a different measure.

Thanks for the pointer to Dan Rawsthorne's material. I agree it wouldn't replace throughput/velocity as you note, but I think it measures "output" more meaningfully for non-IT/engineering folks.

If the development team estimates using typical effort/estimation based points and gets into a reliable commitment and delivery pattern, then input and output match, of course. But a metric for software delivery based on effort and/or complexity while useful for planning doesn't have as much use otherwise outside IT/engineering.

So I guess I like the use of both approaches and see how they can be used independently and allow business to do its pointing and IT/engineering do its with no concern for sharing the meaning or having to participate in making judgment based on concerns/knowledge not available to or possessed by them.

I think that most Agile trainers would no longer recommend estimating tasks in hours. I go one other further - I view tasks as training wheels. They're a useful way to get started but most teams don't need them on an ongoing basis.

Cheers
Mark Levison
Agile Pain Relief Consulting

Hmmm. These value points seem interesting - after a quick read I wonder how different these are from Joe Little's thoughts on the same subject.

Cheers
Mark Levison
Agile Pain Relief Consulting

What I liked about this whole idea was using the acceptance tests as a way to slice the stories into thinner slices without having too many horizontal tasks. I'm not sure that I would want to estimate them. As for the complexity of Antony's tests - I think we would need to see his code which is probably far simpler than the words I used to describe it.

Cheers
Mark Levison
Agile Pain Relief Consulting

Dave,

My response here is to the broader agile community that reads InfoQ. I'm just responding to your post because it provides context.

I understand and largely agree with your points, however...
I'm curious, have you ever gone into a company to execute an agile transformation that had a project management / governance system that relied on estimate based data against actuals and told the folks that their system and their jobs were basically waste?
How did that go for you? :-)

Really, I read a considerable amount about waste this, waste that and I understand the theory deeply(I've read the books), but really, how many organizations go from being waterfall, heavy governance project management (there are alot of them) to the magical world where everyone just trusts in the maximum productive throughput of a team, supports WIP Limits, and management will put their neck on the line hoping for earned value. I haven't found that magic wand yet that can transform an orgaization to that magical state. It takes considerable planning and understanding of the people involved, the culture and the politics as well as the mechanics of organizational transformation.

It would be nice to hear about how coaches actually got organizations to the point where waste was understood and the level of trust existed that allowed for it to be eliminated. Much of this regurgatation of theory and the elusive "no waste" environment is kind of waste in itself.

I've started a blog where I intend to address these issues as well as an often forgotten one, the satisfaction of those actually producing the work. Ensuring their satisfaction in one of the keys to sustainable delivery of value. More to come.

Value points are trying to solve a different problem.
I've written a response on my blog. Excerpt follows:

Value points are solving a different problem and don't help the team estimate what can be done. The value of a story isn't an indication of its complexity. Value, combined with complexity points, can help determine priorities. Arlo Belshey explains some interesting views on this.

Prioritisation is, in my view, one of the few reasons to place some sort of estimate on value & complexity. Unfortunately, it seems to be often used to establish a contract with the team for when something will be done and apply pressure when the estimates turn out to be inaccurate.

So, as you explain in your blog-post, you slice the stories as thinly as possible. That's also a relevant approach in my opinion. Using acceptance criteria to slice the stories is on a similar theme, however, provides a little more context around each progress item. It does, however, depend on scenario-oriented examples or acceptance criteria.

I've added to this point in a response on my blog.

In my original post (linked above) I referenced an approach, blogged about by Jason Gorman, outlining a solution to providing a visible indication of progress that is compatible with the idea of measuring progress with working software. It also works more seamlessly with the solution of measuring throughput trends of the team (e.g. with story points) so that the team can estimate how much can be done in the next iteration.

Having worked with Jason, I can safely say that his acceptance criteria are not vague statements. The approach he blogged about was used very successfully on a project he and I worked on a couple of years ago. It was necessary due to the culture of the organisation (still trying to practice Prince2 but wanting the adaptive benefits of agile methods). As coaches, who visits many organisations, both Jason and I have seen many examples of vague acceptance criteria.

I don't think Jason is suggesting that this be a core practice. Remember, not every team or organisation is at the point where the culture supports ditching estimates.

What I am saying is that, if you are somewhere that insists on attempting granular progress tracking and when tasks feel purposeless then a stepping stone is to use acceptance-criteria as your measure of progress instead.

Eventually, the team will see the limited value of estimation.

There are other points related to this touched upon in this response on my blog.

Yes, it's different but useful to know about for all the readers.

I think it's important for people to understand the question behind each metric. Each metric is essentially helping us to answer a different question. Unfortunately, many people forget the question and focus too much on the labelled answer (e.g. value points, complexity points, hours, velocity, etc).

I've touched upon related points in this follow-up on my blog.

Tasks are indeed training wheels. I also liken it to learning how to do something on paper (as children do with arithmetic) before we can try to do that thing in our heads.

This idea has been around for quite a while... but sadly abused IMHO.

I've talked about this some more on this follow-up on my blog

P.S. I misunderstood the reference to "vague statements"... Neither Jason nor I mention the word "vague"... Mark has paraphrased it that way...

My point still stands that I have seen this quite often and is one of the many things I'm called upon to help organisations fix.

Feel free to see my code :-) Or... better still, see me working for real...

I'm one of the few (I know only of one other) who uploads videos of his development sessions unrehearsed and unedited. pairwith.us has hours of video following the development of a BDD-enabling fit-fixture.

Or, you can see an example of a fluent API created to enable BDD feature specs in Java code... which was an illustration of a better solution to a problem one of my clients was trying to solve. The client has taken the concept and is evolving it internally. We're talking about merging the projects and packaging them for easier distribution.

I think I've addressed the issue of "vague statements" in an earlier comment :-)

It's a step by step process. My role as a coach is often to help people find the right questions to ask of themselves and help them then find the answers that will work for them at that time. Through experimentally applying these answers to what they do the teams and the organisation learn, iteratively, and find new questions. Eventually, they arrive at the understanding that there is a lot that we do because we think we're supposed to, not because we really need to.

One example was where the CxOs (or C-level execs) wanted to reduce the amount of testing their people had to do. The perception was that it was slowing them down. The implementation teams couldn't see how they could do that without slowing themselves down further due to the overheads of fixing bugs that slipped through to production. The question was the wrong question. I worked with them and the implementation teams to understand a more relevant question - how can they deliver more and be in a better position to respond to changing commercial circumstances? This helped to bring about a series of small and frequent changes across the organisation.

If I told you exactly how I did that, you wouldn't need to hire me ;-) But the results speak for themselves.

I feel that, for the more mature delivery teams, the thing holding them back isn't how they deliver but the business culture that influences how the business tries to track delivery and "manage" it (so to speak). I've address this somewhat in a follow-up on my blog:

For pull systems that eliminate estimation as a means of predicting the future to work (such as Kanban), we need a more adaptive approach to budgetary spend. Business needs to find a way to adapt budget allocation more frequently, perhaps as frequently as monthly, perhaps more frequently still. The business now needs to look at how it can respond to change rather than focus on following a budget-plan.

We, those who evolve the implementation of the ideas of the business, have responded to their demands to be able to respond to rapidly changing markets and provide that competitive edge. For the more mature implementation teams, the hindrance now is no longer how we make the products, but the business culture of inflexible and predictive budget allocation.

Sorry about the delayed response. I don't often check InfoQ.

You write, "...and told the folks that their system and their jobs were basically waste?
How did that go for you? :-)"

Short answer is "Yes" and "pretty well."

Better answer, maybe: First, you don't stroll in the door and start spewing negatives all over the place. I've started with introductory explanations of theory of constraints and lean thinking and agile values and so forth, and then proposed helping the client analyze their own process/problems. Waste tends to fall out of such an analysis naturally without making it sound personal or offensive.

Organizations don't change with the flick of a switch, and they almost never change "all the way" to a proposed new state.

The reason you haven't found the magic wand that will transform an organization to a magical state is that it isn't a question of magic. It's a question of hard work.

"I understand the theory deeply(I've read the books)" With respect, I don't think that's what it means to understand something deeply.