Extreme Planner and "drilldown"

[Frank Carver]

I just took a look at the demo installation of Extreme Planner, and in general it seems fairly well organized. One thing which struck me, though, is that many things which I would expect to be links are not.

For example, on the Iteration Status view a failed test lights up in red, but no indication of which test has failed - I tried to click the fail message to "drill down", but no such luck.

Similarly, for some of the tasks there is a label which states "No tests defined", but nothing to click to define a test for that task. I spent a few minutes looking in lots of places, but could still not find where to define a new test.

And again, on the same screen, tasks are shown as assigned to spacific users, but the user name is not a link - it neither takes a user to a page about that user, or (probably more useful) a page which shows all the tasks currently assigned to that user, and their status.

When I go to the list of tasks page, the iterations are not clickable, the users are not clickable, and neither are the status values.

I could go on, but I hope you get the message. To me, leaving all these things as un-clickable text is a real waste of user-interface space. An application which users love (rather than just tolerate) is one which works the way they want, rather than forcing a different model.

Any chance of this changing?

[Dave Churchville]

Originally posted by Frank Carver:
I just took a look at the demo installation of Extreme Planner, and in general it seems fairly well organized. One thing which struck me, though, is that many things which I would expect to be links are not.

For example, on the Iteration Status view a failed test lights up in red, but no indication of which test has failed - I tried to click the fail message to "drill down", but no such luck.

Similarly, for some of the tasks there is a label which states "No tests defined", but nothing to click to define a test for that task. I spent a few minutes looking in lots of places, but could still not find where to define a new test.

And again, on the same screen, tasks are shown as assigned to spacific users, but the user name is not a link - it neither takes a user to a page about that user, or (probably more useful) a page which shows all the tasks currently assigned to that user, and their status.

When I go to the list of tasks page, the iterations are not clickable, the users are not clickable, and neither are the status values.

I could go on, but I hope you get the message. To me, leaving all these things as un-clickable text is a real waste of user-interface space. An application which users love (rather than just tolerate) is one which works the way they want, rather than forcing a different model.

Any chance of this changing?

Hi Frank,

That's useful input. In most cases where something *isn't* clickable, its because there is no obvious screen or view to navigate to, or we were afraid of too much noise on the screen (i.e. every data column in a list having a link).

In the specific case of the Iteration View, tests are defined against Stories, not Tasks, so clicking the Story Name will take you to a place where you can define Tests, more Tasks, etc. It might be useful to also make the message link to story tests as well.

But your point is taken, that it might be better to have the option to navigate however you like, versus having only specific paths defined.

As we continue to update the application, we'll keep these kinds of navigation issues in mind. Your specific suggestions about the User link and the Tests link sound like good candidates for the iteration status view.

[Frank Carver]

Thanks.

You wrote: tests are defined against Stories, not Tasks

Is there any particular reason for this? In particular, how do you know that as task has been completed if there are no tests for it?

Taking the tasks in your demo as examples, the "add a product to my shopping cart" story has two tasks "create shopping cart list user interface" and "implement shopping cart storage code". The tests and implementation for these tasks seem very different and could easily be done by different users/pairs.

So what happens if one task is complete but the other isn't? How does Extreme Planner know? it just seems strange that Extreme Planner is not able to access or manage information about the test status of tasks.

Perhaps I'm missing the point here, though, can you clarify how it is supposed to work?
[ October 12, 2006: Message edited by: Frank Carver ]

[Dave Churchville]

Originally posted by Frank Carver:
Thanks.

You wrote: tests are defined against Stories, not Tasks

Is there any particular reason for this? In particular, how do you know that as task has been completed if there are no tests for it?

Taking the tasks in your demo as examples, the "add a product to my shopping cart" story has two tasks "create shopping cart list user interface" and "implement shopping cart storage code". The tests and implementation for these tasks seem very different and could easily be done by different users/pairs.

So what happens if one task is complete but the other isn't? How does Extreme Planner know? it just seems strange that Extreme Planner is not able to access or manage information about the test status of tasks.

Perhaps I'm missing the point here, though, can you clarify how it is supposed to work?

[ October 12, 2006: Message edited by: Frank Carver ]

Hi Frank,

Perhaps the meaning of "test" here needs definition. Stories have "acceptance tests" which test the entirety of the feature. That is what ExtremePlanner is tracking.

So for "Add Product to Shopping Cart", I might write a test like "Add a single product and verify that it displays the product name and quantity in an on-screen cart". When this feature is complete, this test should pass, regardless of the implementation.

You might also have automated unit tests for specific code modules, classes, etc., but ExtremePlanner doesn't track unit tests.

So yes, multiple users/pairs could work on tasks for the same story, but at the end of the day, all acceptance tests need to pass for that story, and the status of individual tasks isn't very important in that context.

In fact, what winds up happening (at least in my experience), is that some tasks get removed, others get added, but the tests are fairly stable, since they are direct consequences of the requirements, where the tasks are pretty implementation dependent.

Does that make sense to you?

You might find Ron Jeffries short article "Card, Conversation, Confirmation" relevant to this topic also: http://www.xprogramming.com/xpmag/expCardConversationConfirmation.htm

[Frank Carver]

OK. Looking at that article has helped crystalise my thoughts a bit.

I find it interesting that the article does not mention tasks at all. One way of looking at what Jeffries writes is to conflate the ideas of a story and a task into a single concept, which we might as well just call a story.

This seems to be roughly where my mental model of this lies. Stories can be described at several scales and levels of granularity, but they are still stories. So, in the demo example the large scale story "add a product to my shopping cart" can also be considered as the two finer-grained stories "create shopping cart list user interface" and "implement shopping cart storage code". All of these stories potentially need conversation and confirmation as described in Jeffries article.

When I do this with index cards, all the cards are stories, but some get clipped together with others to represent larger or coarser-grained chunks of work. Cards can still be moved about between clipped chunks, or considered as a chunk in their own right.

I find it hard to imagine the value of arbitrarily pushing the customer away from decisions about a shopping cart UI (for example), and declining to associate any acceptance tests, just because it has been defined as a "task" rather than a "story".

Have you seen any major advantages to this sharp separation between the concepts of "story" and "task" in the EP implementation?

Is there any way to "promote" a task to a story if a team does want to apply story-level operations such as associate it with a acceptance tests or move it to a separate iteration?

[Ilja Preuss]

Originally posted by Frank Carver:
I find it interesting that the article does not mention tasks at all. One way of looking at what Jeffries writes is to conflate the ideas of a story and a task into a single concept, which we might as well just call a story.

The difference between a task and a story is that a task isn't defined through business value. And often enough, a story actually is more than the sum of its tasks - Ron often reports from Scrum teams he coaches which happen to finish all the tasks in an iteration without finishing the underlying stories.

This seems to be roughly where my mental model of this lies. Stories can be described at several scales and levels of granularity, but they are still stories. So, in the demo example the large scale story "add a product to my shopping cart" can also be considered as the two finer-grained stories "create shopping cart list user interface" and "implement shopping cart storage code". All of these stories potentially need conversation and confirmation as described in Jeffries article.

I think those are great examples of tasks that are actually *not* stories. They would only be stories if the customer would get business value from only implementing some of them.

I find it hard to imagine the value of arbitrarily pushing the customer away from decisions about a shopping cart UI (for example), and declining to associate any acceptance tests, just because it has been defined as a "task" rather than a "story".

Why would it push him away from those decisions? Wouldn't those acceptance tests just be part of the tests for the "whole" story?

As an aside, if the story is too big, I would rather break it down into smaller "true" stories - such as starting with a very simple shopping cart and have later stories add features such as sorting, drilling down etc.

Have you seen any major advantages to this sharp separation between the concepts of "story" and "task" in the EP implementation?

I can't talk for EP, but for our experience with XPlanner.

What we've found is that we like task breakdown for estimation, but that we actually can't reliably predict how the work needs to be broken down for implementation. We do all the tasks that we estimated, but often in no way in a sequential order. As a consequence, we typically don't track tasks any longer (which in XPlanner basically means that we have one task per story).

[Frank Carver]

OK. I can see that.

It's likely then that I usually work with stories at a slightly lower level than you, then.

I like to deliver stuff. I get a small kick everytime something is completed, and a bigger kick every time something is accepted and/or deployed. With this in mind I tend to negotiate with clients at a relatively fine-grained level. I would see nothing wrong in delivering a shopping cart UI on its own without a storage back-end. In fact, I have occasionally done someting very similar so the client can begin staff training in advance of a live deployment.

Of course this may be a symptom of the kind of clients I have worked for.

Usually I either have one huge monolithic "all the requirements, all at once" story, which I have to unpick myself to measure my progress, or I have negotiated a spread of much smaller stories (maybe bug reports from an existing system), or I am working on a speculative project where I am (in some respects at least) the client.

[Dave Churchville]

Thanks Ilja, you've pretty much answered the way I would have :-)

Frank,

Another way you could approach this is to skip the tasks altogether and use fine-grained stories with business value, as long as "the customer" can understand and prioritize these. This might be a good approach if you are the lone developer.

Then you'd simply create acceptance tests for each small story and mark them as passed. I actually prefer smaller stories, since the estimates tend not to get as far off as larger stories. My personal rule of thumb is to limit the size to about 1 week or less of work.

Tasks are a mechanism for developers to crystallize their understanding of a story and how they will implement it. They are also a way to divide work if more than one person/pair will be working on the story.

The main issue I see with conflating stories and tasks is that if you are not the customer, it gets increasingly difficult to talk about "Customer acceptance tests" for technical details like creating database schemas, doing refactoring on the FooBaz class or "writing the Hibernate integration wrapper".

[Ilja Preuss]

Originally posted by Frank Carver:
It's likely then that I usually work with stories at a slightly lower level than you, then.

Not sure about that. Our stories typically are of the size of 4 to 12 person hours.

I like to deliver stuff. I get a small kick everytime something is completed, and a bigger kick every time something is accepted and/or deployed.

Ditto here. That's why we prefer our *stories* to be small. A task could be something that cannot reasonably be delivered.

I would see nothing wrong in delivering a shopping cart UI on its own without a storage back-end. In fact, I have occasionally done someting very similar so the client can begin staff training in advance of a live deployment.

Well, if delivering only the UI has value to the customer, it's a true story to me.

I probably would try to express the second part more in customer terms, though - perhaps "make the UI actually work" instead of "implement storage backend".

[Mark Spritzler]

OK my mind hurts now.

Actually what I noticed, and I know this has been resolved, was that it looked like Frank was making tasks into stories. Meaning that the stories at the end are not business terms but more technical terms. But Stories need to be at the business end and not the programming end. Like, "create shopping cart list user interface" and "implement shopping cart storage code". Because User Interface and Code are technical terms.

But I also agree with Frank in that I don't want this huge monolithic story like "Add Product to Shopping Cart", because there is no way to possible complete that story in an iteration. It would need to be broken down, because there are a number of elements that all need to be completed to be able to do that one story.

Mark

[Frank Carver]

But Stories need to be at the business end and not the programming end. Like, "create shopping cart list user interface" and "implement shopping cart storage code". Because User Interface and Code are technical terms.

This was something which became much clearer to me after thinking about this dicussion. I hadn't thought much about the choice of stories and tasks in the EP demo at the start (as you can see, my main concern at the begining of this thread was for the usability of the EP UI).

Since reading some of the comments here, I have looked back at some of the "small stories" I have created and/or worked on, and I see a quite different pattern.

Even my small stories tend to have business value, because I split each conceptual larger story in a different way. Where the EP demo has "UI" and "storage" as tasks withing "create shopping cart", my approach would be to divide it into much smaller business-value stories such as "show cart button takes the user to a shopping cart screen", "shopping cart screen shows user id", "shopping cart screen shows list of items", "initial shopping cart is empty", "buy button adds an item to shopping cart list", "delete button removes an item from shopping cart list", "clear button removes all items from shopping cart list", "checkout button takes the user to a purchase screen", "purchase screen shows same items as the cart list", and so on.

It appears to me that the EP demo splits the large task "horizontally", where I guess I would try to split it "vertically".

Some or all of these small stories may involve back-end storage, session management, or whatever, but that's a technical aspect which is glossed over in the stories. If a story (such as "show cart button takes the user to a shopping cart screen") obviously does not need back-end storage, then don't code it. Deliver the story and move on. The key point is that they all provide separate business value and can be prioritised and/or omitted for any given release.

Co-incidentally, I also find that this style of story aligns much more intuitively with the acceptance tests. Writing sensible acceptance tests for a large story such as "shopping cart" is not an easy job, and can often descend into a lot of man-hours spent in meetings and wrestling with documents. The acceptance test for "checkout button takes the user to a purchase screen" is almost too obvious.

Does anyone else work like this? Are there any obvious or subtle problems I'm missing?

[Dave Churchville]

Originally posted by Frank Carver:

Even my small stories tend to have business value, because I split each conceptual larger story in a different way. Where the EP demo has "UI" and "storage" as tasks withing "create shopping cart", my approach would be to divide it into much smaller business-value stories such as "show cart button takes the user to a shopping cart screen", "shopping cart screen shows user id", "shopping cart screen shows list of items", "initial shopping cart is empty", "buy button adds an item to shopping cart list", "delete button removes an item from shopping cart list", "clear button removes all items from shopping cart list", "checkout button takes the user to a purchase screen", "purchase screen shows same items as the cart list", and so on.

It appears to me that the EP demo splits the large task "horizontally", where I guess I would try to split it "vertically".

Some or all of these small stories may involve back-end storage, session management, or whatever, but that's a technical aspect which is glossed over in the stories. If a story (such as "show cart button takes the user to a shopping cart screen") obviously does not need back-end storage, then don't code it. Deliver the story and move on. The key point is that they all provide separate business value and can be prioritised and/or omitted for any given release.

Co-incidentally, I also find that this style of story aligns much more intuitively with the acceptance tests. Writing sensible acceptance tests for a large story such as "shopping cart" is not an easy job, and can often descend into a lot of man-hours spent in meetings and wrestling with documents. The acceptance test for "checkout button takes the user to a purchase screen" is almost too obvious.

Does anyone else work like this? Are there any obvious or subtle problems I'm missing?

Interesting point, Frank.

I don't see any problem with your approach, you're just using a smaller granularity of story, which I agree can make things simpler both to discuss and to implement.

The point is really that it's the customer that should be writing stories (with help from the development team) that are meaningful to them.

The developers are free to subdivide into whatever tasks are meaningful to them (or not).

From my own experience, it can be difficult for customers to directly prioritize very small stories. In this case, you might want to categorize a set of small stories into a "topic" or "theme", and have the customer first prioritize high level topics, then figure out which subset of stories make sense.

"Shopping Cart" might be top priority, for example, followed by "Accept Credit Cards" as topics, each with 5 or 10 stories under each.

It's also pretty desitable to create stories that can stand alone as useful business functions, or can be omitted without making other stories useless.

Thanks for the great discussion here.

[Ilja Preuss]

Originally posted by Frank Carver:
Does anyone else work like this?

Yes! Oh yes, yes, yes! That's what I was trying to get at, actually - sorry for not bringing it across appropriately...