Comments on Agile + UX = idealized vs. current state

Jon Moore — Wed, 16 Apr 2008 01:58:49 GMT

Liked the “slow software” article. We’ve definitely started to go down this path somewhat, so I think there would be some traction with the team on this. This can be seen by trying to write our user stories to be end-user-centric (rather than ones that begin “as a product manager, I want”) plus I think our iterations are starting to look like “one big, deep, new feature plus a bunch of minor cleanup tasks.”

Re: backlog. I think the IA bucket was what I was trying to describe in my previous comment (I just forgot what we called it). We do already have the “engineering bucket” that gets filled by things off the “tech backlog.” Incidentally, the tech backlog is maintained by the engineers, so perhaps IA could maintain the UX backlog, and pick off a couple of things to suggest for each sprint a la the engineers and the tech backlog.

As far as the backlog being a ghetto, I think you’re right, but I also think this is a factor of having a very full roadmap of ideas and a fixed capacity for turning those into production code. Also, I think the gaps you’re talking about may not be all that bad—we may end up revamping or removing a feature before we get around to getting it all the way to perfect. To me, this is one of the benefits of timeboxing a sprint—it forces you to make the tradeoffs between have 80% now or wait for 100% later. And the choice isn’t always 80% now—just yesterday we had the product team push a story to the next sprint rather than implement a degraded version of it.

Austin Govella — Tue, 15 Apr 2008 17:01:53 GMT

Hey Jon!

I found this great article from Jeff Patton on what he calls the “slow software movement’: * http://agileproductdesign.com/blog/slow_software.html

I think your focus on feature scope vs. code quality is really interesting. I prefer to prioritize experience or product quality. I’m more interested in the gestalt of the engineering + the features + the experience.

I feel like a lot of time, the project focuses on engineering or features, which makes sense, since they’re more concrete.

Frankly, the backlog is a ghetto. Things go in and rarely make it back out. There’s a lot of political pressure and shifting priorities that cause this to happen, so it’s not the backlogs fault, but that definitely means the backlog, by itself, isn’t a good answer.

We used to have the “IA bucket”. That seemed to work well. Maybe re-instituting the bucket would be a good thing? We used to use it for bug fixes, features, and design scrubs: all the “experience” things. And maybe there should also be an “engineering bucket”?

Definitely, we should write a ticket as soon as the gap appears. That’s an awesome idea.

Jon Moore — Sat, 12 Apr 2008 05:24:51 GMT

Hey, Austin. Very interesting; there are definitely analogs on the engineering side, where we make some compromises to get a feature out the door. Most of the time we try to shrink feature scope rather than sacrifice code quality, which contributes to the gap you mention. Sometimes, though, we jam a feature in, even if it’s not *exactly* the right way, and then we’ve created an “engineering gap” for ourselves.

We actually track this by maintaining a “tech backlog” and we try to tackle a couple of these things each sprint; perhaps there could be an IA backlog of gaps. If product is into it, perhaps a small amount of each sprint could go into reducing the IA gaps, just like a small amount goes against tech backlog. At the very least, the gap could get documented as a new user story, with the idealized vision virtually stapled to it, so that it doesn’t get forgotten. Probably ought to be part of the sprint review, although if we’re doing the collaboration right, we ought to be able to write that story as soon as we realize we can’t get the whole way there.

Crystal Kubitsky — Tue, 08 Apr 2008 19:23:29 GMT

Brilliant, Austin! I couldn’t have articulated the scenarios and observations any better. Our team’s really are similar in this respect and there’s much we can learn from each other!