When reading this Kill Your To-Do List blog post, I thought that managing personal to-do list can be similar to product backlog management. Not in the part that you should totally kill your product backlog, but in the "one thing at a time" part. This is by no means a new thought. E.g. Mary Poppendieck was heard saying that product backlog should be eliminated.
So, as in to-do lists, there's no point in nurturing and moving product backlog items back and forth. In this case, a lot depends on what is your definition and understanding of product backlog. I'd say backlog is an environment in which a product grows and exists but not a set of components that should be implemented for sure. Looking further into, what kind of environment is it? Backlog might be a repository of all the slightest shades of ideas that have a very vague chance to be implemented. A chaotic heap. This heap can hardly be called a "backlog" but rather a by-product of brainstorming. OR a product backlog might represent a careful selection of user stories that will be implemented for sure.
Both of these options, as often is the case, have the optimal state somewhere in between. In our production workflow, we're now using several buffers - the first layer is raw Requests and Ideas (coming from our HelpDesk, or from the PO, or from the team). The second layer is Product Backlog with User Stories (Requests and Ideas are now groomed and converted to User Stories by Product Owner who decides that some time these will be implemented for sure - based on how many people requested this feature, based on current product development strategy etc.). The third layer is Planned state for User Stories in Kanban board.
Here's a quick graphical representation of this product backlog upward funnel:
That's how User Stories lifecycle looks on Kanban board, from Planned state on:
Backlog is not seen on Kanban board. When done with their current user stories, developers pull new user stories from Planned state.
Previously, when we worked with iterations before switching to Kanban, there was no buffer between inception and implementation - so time-boxed releases and iterations have been planned directly from the backlog. With Kanban, the buffering is done by moving stories to Planned state and prioritizing them.
I'd say that planning with iterations provides less flexibility than planning with Kanban. As you drop user stories to time-boxed iterations, you commit to implementing all of them within a given period of time. Kanban is way more flexible since user stories can be pulled one-by-one from Planned state and implemented with no time restrictions. I can't resist citing an analogy here: it's the same as moving with the smallest possible steps to posture yourself before hitting the ball in tennis. With large steps, you do not have flexibility. With small steps - you're very agile and flexible to position yourself for the perfect shot.
So, the buffered Planned state in Kanban is like this breaking down into small steps, instead of taking one giant leap and committing to the whole pack of user stories in iteration.
That's the way it goes for us. You're better off moving by small steps, taking it one-by-one (this brings us back to the inspiration blog post reference in the beginning 🙂 than with giant leaps.
If you experience some problems with TargetProcess performance on your server, don't be in a hurry to blame it on the product. Most likely, these problems are related to hardware and software configuration on the server.
We've put up a page on TargetProcess web-site with some tips on how to speed-up investigation of performance issues:
TargetProcess on-demand and on-site accounts have been updated to build 2.19.5.
Let's see what's new in this build:
#25620 On-demand scheduled maintenance notifications added
Now you're notified of scheduled on-demand updates and it's possible to plan your work accordingly. The notification may look like that:
#24719 HelpDesk Portal: separate lists for Ideas, Issues, and My Requests
That's how Requests have been shown in TargetProcess HelpDesk previously. All Requests in one list, no matter if it's an Idea or an Issue:
That's how it looks now - Ideas and Issues in separate Tabs:
#26691 Email integration: Can't send mail. Contact cannot be resolved
#26674 Installation failed in case Database is case-sensitive
#26670 Comments sorting works incorrectly
#26601 Assign Team Members: drag and drop fixed
#26443 "The field Description should not be empty" message appears when comment is copy pasted
If we think about conferences in general, the traditional understanding is: people come together to share their knowledge, to learn, to discuss, to network etc. Some people expect that if they attend a conference they for sure must learn something totally new, something that will change the way they work or even their lives. Some people come to see who's out there, to network and to have some fun. In a nutshell, as many people as many reasons to attend conferences 🙂
I tend to think that with all the information we're consuming, it's very hard to come up with something totally new to a thinking and knowledgeable audience. If you're engaged in agile community, and if you're a thinking person, you thrive in the blogosphere and you practice agile - it's hardly that something will be totally new to you ("totally" is the keyword).
Recently we attended Agile Central Europe conference in Krakow. I'd say that my #1 enjoyment about this event was live cross-twittering. Broadcasting Agile CE to the Twittersphere has really been fun. I liked tweets by Andy Brandt, Marc Loeffler (aka scrumphony), Pawel Brodzinski and Robert Dempsey (for the two latter, it's not only tweets, but their presentations that I enjoyed) . As opposed to most attendees, I didn't very much like the closing show by Gwyn Morfey and Laurie Young. The guys have done a great show, but it was more about dramatic presentation of what's going on in any dynamic agile team 🙂 I've seen a bit of those "paper sword fights" 🙂
After attending Agile 2009 in Chicago, I've really got a little bit skeptical on the conferences overall because what I've seen was people talking about simple truths but with such an air as if they were uttering epiphanies. So, when going to Agile CE I wasn't expecting epiphanies. It was more about going out there with our team, watching people and taking every opportunity to enjoy everything that comes up on the way (including live jazz night in Krakow).
This approach worked better than huge expectations. Strangely, this small cosy conference has become an unexpected source of inspiration. In a sense, that it's not always you have to come up with an excellent new topic or idea no one else knows about. The main thing about conferences is confidence and freedom to express yourself, share your personal experience and absorb experience of others. Somehow someone will find it useful. There's no need to be afraid to appear too simple. People will listen and admire even if this is your first experience as a speaker.
And.. it's great that there're many more agile conferences to come 🙂