Alan Francis's dashboard

Hi Mark,

PodTweet needs to be running to "watch" your iPod playing. Sadly, there's no background processing on the phone. This means you always need to go to the iPod app, start an album/playlist/whatever, then switch to PodTweet.

However.... while PodTweet is running, it will "watch" your iPod and update the text and cover image whenever a song changes. By default, it won't tweet unless you press the button, though.

You can change that behaviour.

If you go into Settings.app and scroll down you'll see the PodTweet icon.

In the settings you'll find an autotweet option which (by default) is set to never. This means you have to press the button each time you want to tweet.

You can change this to autotweet each time the song changes, or each time the artist changes.

Again, these settings only work when PodTweet is running.

Until there's background processing, thats the best we can do. :-(

Does that answer your question ? If not, please get back in touch.

Thanks for trying out PodTweet!

"It still seems like a cleaner solution to allow bugs/chores to have estimates that bump features but don't count toward velocity, though."

Yes, yes, yes. :-) What concerns me is switching to them having estimates *and* counting toward velocity. I think that would be wrong. the estimate on a bug has relevance to the current iterations Budget, but not future iterations velocity (imo).

" I get too many Feature stories on my plate if I have many bugs during that iteration."

This should only happen for one iteration. Next iteration your velocity will be lower as you didn't get all those stories done, so you dont get so many features on your plate.

Yesterdays Weather is marvellous for this kind of self-correction. – Alan Francis, on January 22, 2010 22:54

I think if you are fixing a lot of bugs it *should* affect your velocity reporting. You will get less useful stuff done if you let quality slip and start spending a lot of time fixing bugs. If you choose to schedule a bug in, something else isn't going to get done, but you don't get to keep the points. You spent 2 days fixing a bug instead of delivering a feature. – Alan Francis, on January 22, 2010 22:52

Sorry, this is a bit rambly,

I think there are two concepts at play here.

Velocity = how many feature points I got done last iteration
Budget = how many points I can sign up for in this and future iterations

At the start of a new iteration, we set Budget to equal Velocity. We can now forget about Velocity until the start of the next iteration and deal with budget.

If I add a bug into this iteration, an estimate on it would take out a chunk of the Budget and drop a corresponding feature out the bottom. My Budget is unchanging.

At the end of this iteration I calculate my new Velocity based on the total delivered feature points (this excludes bugs).

What's interesting to me is that in effect Velocity (an output value) works fine when bugs dont count towards it. If you do a lot of bugs, you get less done, so your points achieved goes down.

This means your corresponding Budget for next iteration goes down.

This works well if bugs are scarce and unplanned, added to iteration N mostly as a result of stuff we did on N-1.

"Why did our velocity go down and why didn't we hit what we signed up for?"
"We added a lot of bugs during the iteration.
"What does that tell us"
"We did a bad job of quality control on the previous iteration, so we do need to slow down and do less, but better."

Where it doesn't work so well is in doing iteration planning with a known set of bugs. If I want to deliberately spend my Budget on some features and some bugs with impunity, they *have* to be accounted for in my (output) Velocity so they can be used in my Budget going forward.

I think this split in usage is at the crux of why this question has caused so much debate..

With the former view, the current behaviour is technically right on the money. A bug added during the iteration will likely mean a feature doesn't get done and velocity goes down.

The only problem is we learn that too late. You don't see that knowledge reflected in the plan until the end of this iteration when velocity is measured and the plan reflows to accomodate the not-done feature. If Bugs had size we'd see the knockon planning effect immediately as the story would drop to next iteration and the release plan would reflow. In essence this is what I'm proposing. A Bug introduced to an iteration should knock out a story if it puts us over budget.

Tracker doesn't seem to be designed for the latter approach, where bugs are sitting in the backlog and being scheduled like stories. We effectively gather up a big bunch of bugs using Tracker as a bug database, and then choose some bugs to plan into every iteration along with features with eyes open. In that approach velocity doesn't equal features done, its about work done and all work that gets ticked off in an iteration "counts" for scheduling purposes.

In an XP team, the first view is the predominant approach. Theres a zero tolerance approach and if a bug is found, it gets allocated and fixed, no debate. If there are too many bugs, velocity goes down and down as we're spending too much time fixing bugs instead of writing new stuff.

I'm tired now and going to bed :-) – Alan Francis, on January 22, 2010 22:48

I'm not really in favour of that level of configurability. That's the big problem with Mingle. Too many options.

I think the simplest thing is for every single type of thing I can schedule requiring an estimate and contributing to velocity.

Simple, consistent. – Alan Francis, on January 10, 2010 18:32