Tasking User Stories

At a recent Agile group meeting in Kansas City, the discussion of tasking user stories came up. In principle it simple enough, have the team break a user story into tasks at the beginning of an iteration and then use the tasks to plan the work and track the progress through the iteration. In practice it’s a little more complicated than it appears on the surface.

There are a number of things to consider when tasking the stories: capturing all of the tasks associated with the story, having all of the team member involved with the tasking vs. only the one or two members of the team are planning on working on the story, making sure the tasks are granular enough so they can be forecast, but broad enough to allow for just in time discussions.  It takes a lot of energy to focus on defining two weeks worth of tasks for multiple developers. What follows is a list of some of the do’s and don’ts Visionpace has found while working on our projects.

Things to do:

-         Task the stories one at a time, and have all members of the team participate on the breakdown of the tasks. If one or two members are disengaged have them write the tasks to bring them back into the discussion.

-         Have the members of the development team, the ones that will implement the tasks write the tasks vs. having a non-developer write the tasks. These cards are for the developers and can have lingo or acronyms that might get lost in translation.

-         Use free form design and light weight modeling to describe the story and lay out the tasks. 

-         Have a facilitator that keeps the discussion moving. There needs to be some architecture discussion here, but it shouldn’t be too detailed. As noted above, effective tasking takes skill and effort.

-         During the iteration, if new tasks are constantly being discovered, go ahead and re-task the remaining story.

-         Use an iteration burn down chart to track estimated hours of work remaining for the iteration. Update it ever day after the standing meeting.

-         Have a standing meeting ever day based on the tasks.  This leverages the tracking benefit of breaking the stories into tasks.

-         Make sure the effectiveness of the tasking is a discussion point during the iteration meeting.

-         Have a list of common tasks listed in the war room to help facilitate the discussion. Also update the list of common tasks specific to the project at hand.

Things to avoid:

-         Don’t fall for the logic of, “That story involves XYZ logic and Jane is the only who can crank that out, so she should task it”. You’re giving code ownership to one person vs. having the team own it. In this instance challenge the team to task the story without Jane (Take away the crutch they used and force them to take a step or two.)

-         Don’t add tasks piecemeal through out the iteration. If there are one or two things that were missed, don’t sweat it. If there is more to it, stop and capture all of them at one meeting. 

-         Get too comfortable with the members of the team saying, “I worked on such and such. We don’t have a task for it and don’t need one because it was a one time thing.”  If it’s important enough to work on, it’s important enough to write a task card for.

-         Don’t expect to master this aspect of agile development over night. Inspect and adapt this as with everything in an agile project. Have open and direct conversations about what’s working and what’s not.

I’ll update this list periodically, or perhaps another member of the Visionpace team will.  Just remember that tasking is a critical component of agile planning and tracking and like everything else with agile development, it’s a skill that has to be honed for all members of the team.

Thoughts or comments?  Please let me know Molson@visionpace.com

Interview the the father of Java: James Gosling

Canadian-born James Gosling is the father of Java.  Recently in Canada speaking at a Java conference, the Sun CTO spoke for an hour with Dave Ebner of the Globe & Mail.  The interview goes through James' surprise that Java took off like it did how North America is lagging behind the rest of the world in telco services (he uses Japan's NTT DoCoMo as an example of doing it right).

A short, but interesting read that gives some insight into an amazing piece of computing history.  Java.

Tags: James Gosling, Java, Sun, Sun Microsystems

Ruby on Rails moves to 1.1

Ruby on Rails (RoR) is another of those hot development topics right now.  I've used a few Ruby based applications and have been generally impressed.  The main benefit of RoR is the ease of deploying AJAX (COMET?) apps.

The Web Services Journal and Internet news cover this new release of Ruby.

From the Web Services Journal, here are the what's new in RoR1.1:

What's New In Rails: (complete list here):

• RJS - Write your Ajax application's Javascript in Ruby
• ActiveRecord++Rails' ActiveRecord is a powerful, automatic Object/Relational Mapping tool.  It gets a major steroid boost in Rails 1.1.
• API Support - Adding an API for your Web 2.0 software is now even easier
• New Integration Tests - Rails understands testing and adds even more automatic test support
• Backwards Compatibility - Even with 500 new changes, old Rails apps will almost universally run in Rails 1.1

Like my previous post about COMET, these new development platforms are pushing applications to a new level of development/deployment speed and user interactivity.  Exciting times!

Tags: Ruby on Rails, Ruby on Rails 1.1, RoR, RoR1.1

Catching the tail of COMET

From the Irish Developer Network I found this very thorough description of AJAX's next phase--COMET.

The article goes into detail (not too much) on the architectural differences between AJAX and COMET.  The main benefit, and if you've tried any of the online apps below you've seen it yourself (I like the GMail-GTalk integration myself), is that COMET is more persistent with long-term connections.  Activities that take time to complete.

• GMail’s GTalk integration
• Jot Live
• Renkoo
• cgi:irc
• Meebo

So the question is, should more apps be moved online via AJAX or COMET?  I'm not so sure.  I still live in an online-offline world, so I need applications that run when I'm not connected.  That being said, I see a lot of potential for internal applications like expense reports or maybe even group spreadsheets and word processors.  Even an internal IM system might be a good application.

What do you think are the AJAX or COMET apps that have the most potential?

Tags: COMET, AJAX, web development, online applications

When the story doesn’t fit

On a recent .NET consulting project in Kansas City, where we were doing software development and agile project management coaching, the team was struggling with sizing our user stories to fit our iterations.

Invariably during our projects we find that some of the user stories we came up with during the initial story workshop don’t really fit in the project development as written. Sometimes they are too large for the time allotted and/or have some high priority tasks and some not so high priority tasks. Other times we’ve learned so much about the project, the initial story doesn’t encompass all the facets it should. The question is what to do with these stories. Should the entire story be tasked out and carried over to the next iteration, should only the necessary tasks be focused on, and the story carried over, or should the story be broken down into smaller stories?

The answer, like a lot of answers when following an agile approach is; it depends. One can make an argument for any of the scenarios listed. Since I’m the kind of person that has a ‘I want to show progress on the burn down’ perspective, I prefer to break the story into smaller stories that ‘slice the cake’. (The stories aren’t all user interface or all back end processing. Rather they have some user interface, some middle tier logic and some back end processing.) What’s important is to capture the stories based on the current understanding, scope them in an appropriate size as much as possible so they don’t have to be broken down again later, and make sure that nothing falls through the cracks.

Once a story is broken into new stories the next thing to consider is how to forecast the new stories. Often times there is the desire to say that since the original story was forecast as a five points, and since we broke it into three new stories, one story that is three points, a second story that is one point, the remaining story must also be one point (5=3+1+1).  Don’t do this.  Another pitfall is for the team to say “When we started these stories would have all been threes, but since we have a better idea about what we’re doing, they all look like one’s now.” The key is to forecast each of the resulting stories independently and triangulate them against the existing stories for the project, making sure they are put in the right bucket.

The take away is to make sure the user stories reflect what you are doing in an iteration rather than trying to make the iteration fit the stories defined. If this means that some stories need to be removed and rewritten, do it. Just pay attention to the stories that are created to make sure they will fit in the future and that you don’t lose anything in the transition. Also remember that the forecasting for the stories follows the same triangulation used in the original story workshop.

Software Inventory

How much money will the organization make or save by having a new software feature in use?

The process of prioritizing the selection of proposed software features based on business value and determining the business value of software features can be as much an art as science. Beyond the more obvious examples of forecasted new sales or cost reductions that some software features somewhat easily map to, most features and their underlying business value are harder to determine.

Return on investment (ROI), Payback Period and a number of other approaches attempt to assign a tangible value to software features for purposes of making decisions on what to build next and in most cases, entire projects or release items. While these methods do work in a number of circumstances and are getting better in aiding business value prioritization, often times it comes down to the intuition of business domain experts. The people that are closest to the business problem the software features support can often see the value of a feature, at least relative to other features.

Having done software development and consulting in Kansas City for some time, one of the most important points of analyzing the business value in our opinion has been to have the discussion in the first place. Regardless of the analysis and approach used (ratios, intuition, etc.), merely spotlighting the need to make decisions on software features to build based on the value they'll add to the business (and how soon they'll add it) is a significant positive step. Another important point is to continually revisit the value discussion throughout the project not just in the beginning. Learning is a part of any software development (or any R & D process) project and a lot can change and be learned during the course of development efforts. Learning also takes place as business stakeholders see software features in action so getting working, tested features in at least a staging area to promote feedback is important to revisit business value discussions. Having business domain experts (armed with the latest intelligence about their domain [market changes, organizational changes, etc.]) reviewing features is critical for moving software out of inventory and into the business and adding value.

Take a look at your software inventory. Some say that any software development item not being used by your customers/users is considered to be in inventory and therefore doesn't have any real (tangible or intuitive) business value. Some items such as certain project artifacts (documentation, models, etc.) will never leave inventory status so carefully decide their importance in understanding what needs to be built or perhaps create throw-away artifacts, spending just enough time to reach an understanding about a particular issue and moving on.

The goal is to put things in inventory that will ultimately be valuable and then move them out of inventory to begin delivering value to an organization as soon as possible. And, if you're wondering what's valuable (working code, certain artifacts, etc.) to your customer or how they would like you to spend their money -- ask them.

Office 2007 delayed to match Vista

It's official, Office 2007 has been delayed to better match the launch of Vista in January 2007.  According to a Microsoft release, Office 2007 will be available in October of this year to volume business licensors and OEM distributors.

What I really wonder is, though, if Office 2007 is going to leverage Vista features, why would you bother buying it before you get Vista?  The logic escapes me.  And frankly Office has one of the slowest uptakes of any MSFT product.  Come on, how many people really notice a difference between Office 2000, Office XP, and Office 2003.  Having run all three ... I can't really see much, at least from a day-to-day standpoint.

It's going to be a tough, uphill battle on both these fronts.  Frankly, I hope Microsoft seeds the tech community, liberally, with free copies of Vista and Office 2007.  I'm not going to lay down the cash myself until I see/hear some real tangible benefits.  Okay at least until the first service pack comes out ;-).

Tags: Microsoft, Vista, Office 2007

The Vista saga continues ...

Continuing on the "Vista is delayed" theme, there was some discussion today the 60% of Vista has to be re-written for launch.  Given what I've personally seen and talking with Vista testers, I agree with Robert, it's rubbish.  I guess it's not surprising that people might jump to this conclusion.  My take is this.  XP hasn't done awesome in the sales and upgrades department.  On top of that, Microsoft always takes it on the chin when a new OS comes out (the refrain I hear is ... wait until the first service pack).  So why not delay it and maybe boost people's security that it's worth upgrading sooner rather than later?

Makes sense to me.

Tags: Microsoft, Vista

Filling out web forms rots

Chris Breisch has a great post "Death By a Thousand Textboxes" where he laments about web forms where you have three boxes instead of one to fill in a phone number.  Those actually only really bug me if the active form cell doesn't jump to the next one as you hit the right number of digits.

That being said he does close the post with a great bit of UI advice that is well worth remembering ... for all the UI work we do:

I think UI experimentation is not only desirable, but necessary. If we don't experiment, we can't evolve UI forward. However, you have to do it the right way:

1. Have a complete understanding of the current convention and how it arose
2. Have a good, reasoned argument for deviating from the convention
3. Collect usage data on your experiments
4. Make decisions based on the usage data

If you're not collecting usage data, or your reason is "it looks better this way", then you're doing it wrong, and you should stick with the conventions.

Tags: web development, software development, UI

.Net and C# coming to the Mac?!?

Wow, this could be huge ... if it stays on track, of course.  This actually hits pretty close to home.  When we were looking at the next version of Qumana we knew we needed a PC and Mac version.  Then, the only viable option was something based on Mozilla (sounds great, lousy documentation) or Java (well supported, but rather sluggish).  Rumours and whispers of something like this were tempting but far too vaporware to base a real development plan on.

The big question is, will this matter?  Will a lot more apps be written so that Macs can use them?  That's tough.  As much as this is touted as a "cross-platform solution" I know from the Java experience, you will have to tweak for Mac and PC.  It will come down to ... is there a large enough user base to warrant the additional development?

I guess we'll just have to wait and see.

Oh, the image above?  That's a test widget in this new programming tool ... in Firefox ... (credit to Adam Kinney)

Discussion: Wired, MSDN

Tags: .Net, C#, Mac development, Microsoft