Agile Bench

Get the Story

Agile Bench header image 1

Better agile planning with projected iterations

April 13th, 2012 · Agile, Agile Bench

We see a lot of deep backlogs. Teams that practice agile planning usually have a well groomed backlog towards the top and the bottom of the backlog is, well, closer to a list of ideas than actual stories. But that’s ok!

Project planners (like the CEO of a small company, the product manager or technical lead) want to get a feel of what the next few iterations are going to look like but don’t want to assign stories to iterations just to see how much work they can get done. So we’ve created projected iterations.

Projected what?

Nobody can see the future, so all we can do is guess what the future will look like. We use fancy terms like “projected” and “extrapolated” to make us feel better, but at the end of the day they are our best guess given our current information with a few assumptions mixed in for good measure.

With this in mind it would be great if our planners could see what the next few iterations may look like and that is where projected iterations come in. Agile Bench takes the team’s velocity and uses it to assess what future iterations may contain and visibly shows these projected iterations within the backlog.

agile planning with projected iterations

(click to enlarge) This project has a velocity of 13. There will be a projected iteration at 13pts, 26pts, 39pts, etc...

It should take away some of the manual counting we see teams do when they are trying to work out what is roughly going to be in scope for the next few iterations.

We see this feature being enhanced in the future. We’d love to know what you think and if you’ve got any ideas.

Go on and sign up for a free trial from our homepage and test it out for yourself.

A special thanks goes to Roman Pichler (@romanpichler) as we’ve references two of his articles in this post.

→ No CommentsTags:····

Features – the categorization of stories

November 25th, 2011 · Agile Bench, Features

Stories are great.  They allow agile teams to express their work in units that are valuable to you, their business owner.  They can be estimated reasonably well since they’re small and they can be traded off against each other and prioritized by you, the business owner.  The down side of stories is that you have lots of them which can make it hard to see the big picture.  How do you see the wood for the trees?
To better understand a mass of information, we generalize and we categorize.  Agile Bench has added the “Features” feature as a way of categorizing stories.  Each story can now belong to a feature allowing you to break your stories into business oriented chunks.

Features are stories categorized into business oriented groups

We’ve worked hard to make features easy to use.  Features can be added whilst editing a story.
Or you can bulk edit your backlog stories and add them (or remove them) from a feature.

Categorize features in bulk

We’ve also got a page to manage your features.  On the Manage Features page you can add, edit, delete and color your features.
Once you’ve categorized your stories you can quickly filter the backlog and get insight into how big the feature is.  We’ll have another post on search soon.

Quickly show only the feature you're focused on

Features give you a very powerful way to slice and dice your backlog.  Let us known how you find it.
Mike Cohn, of Mountain Goat Software, has a good article on features (although he calls them Themes).  As he notes, the terminology isn’t that important as long as everyone agrees on what it means in their context.
On an aside, Agile Bench currently has epics, which is one of our issue types.  We don’t recomment using epics as we’ll be phasing them out soon.

→ No CommentsTags:······

Keyboard Shortcuts – from Novice to Ninja!

November 22nd, 2011 · Features

I use Google Mail (GMail) a lot.  In the past, I’d hunt and peck with my mouse to read a new email and archive it, to move between folder and to tag items.  When I learnt about keyboard shortcuts my life changed for the better.

To truly be productive with an app, you need to be able to navigate the app without your fingers leaving the keyboard.  To this end we’ve introduced keyboard shortcuts.

keyboard shortcuts - click to enlarge

On the “Backlog and Planning” screen you can press “?” and bring up the help menu.  The Story List now has a cursor, shown as a blue bar on the left of the first story.  The cursor can be moved up (with “k”) and down (with “j”) and stories can be selected (with “x”).  The bulk editing buttons up the top of the grid can be enabled with keystrokes too.  You can quickly tag (with “t”) your stories, move them to an iteration (with “i”) and categorize them as a feature (with “f”).  Search can be easily accessed (with “/”) as can new story composition (with “c”).

Not only have we added keyboard shortcuts, but we’ve also make it easier to navigate around the app with the TAB key.  The focused elements highlight to give you a visual indicator of where you’re up to.  It’s pretty nice.

At the moment, keyboard shortcuts are limited to the “Backlog and Planning” screen.  We’ll expand their coverage over time.

We’d love you feedback.

→ No CommentsTags:··

Agile teams need to iterate

October 4th, 2011 · Agile

In the previous post I wrote about how trust was key to getting the most from your agile teams.  In this post we’ll continue looking through the Lieutenant Commander’s finding from his paper “Communicating Intent and Imparting Presence“.

The Lieutenant Commander ran and experiment to test the doctrine of the Commander’s Intent.  The iterative approach to decision making and high levels of communication were highlighted in the article.

“Successful company commanders that matched their battalion commander’s intent initially determined the disposition of friendly and enemy forces.  They specifically referenced procedures and the intent statement in the battalion OPORD.  They also acknowledged that they had to coordinate their activities with commanders of adjacent units prior to taking any action”

I’m going to extrapolate this finding to say that it is also needed to run a successful project.  There are two parts to this paragraph – follow the intent and work with others to achieve your goal.  Although neither of these two items are listed in the Manifesto for Agile Software Development, it’s pretty obvious that if you ignore these then you’re not very likely to run a successful project.

Iterate to continually improve

The paper highlights what makes certain commanders unsuccessful including:

  • Did not refer to the battalion commander’s statement of intent.
  • Exhibited flawed tactical knowledge
  • Rigid adherence to procedures despite new information that indicated they were facing a novel, unanticipated situation.

Which I’ll translate as:

  • Did not clarify that the goal they were working towards was the actual goal
  • Did not have the technical knowledge to build the software
  • Did not adjust the plan when new information changed the situation

Points two and three have obvious consequence to agile teams.  Point two refers to issues with technical abilities and one of the agile manifesto’s principles is “Continuous attention to technical excellence and good design enhances agility.”  At the ten year retrospective of the signing of the Agile Manifesto the number one success factor of agile teams was demanding technical excellence.

Point three is embedded right into the heart of Manifesto for Agile Software Development – we have come to value “Responding to change over following a plan“.  Iterate.

How do we help teams to work better?

We need to spend more time communicating intent.  Both managers and their teams need a shared understanding of a projects goals and intentions.  It’s too easy to say “build widget X” when instead, as leaders, we should be explaining the issue widget X is attempting to solve.  Understanding the rationale behind these decisions aligns teams and also teaches your team how see a problem and solve it in the same way you would, making them more likely to be self sustaining.

Investment in technical skills and prioritizing technical excellence is also critical to succeeding in software development.  It’s a tough one as software professionals have been incorrectly (incorrectly) depicted as a commodity over the past ten year.  Good people are hard to find, especially in highly technical areas and we cannot to treat them as disposable items.

Finally, we need to continually revisit the plan.  Teams need to look up at the horizon with their leadership teams and make sure they are properly aligned.

We’d love to hear your thoughts and comments.

→ No CommentsTags:······

Agile Teams need to be trusted

September 27th, 2011 · Agile

Don’t run away!  I’m going to use the military doctrine of Commander’s Intent to highlight a project management issue.  I’m not a big fan of using military example as they are often gung-ho, misdirected, chest beating exercised to make a writer feel like they are king of the hill.  Disclaimer aside, the doctrine of Commander’s Intent is fundamentally about centralized versus distributed decision making and anyone participating in a project can learn from the approach.

The Commander’s Intent, the Agile philosophy and New Product Development approaches share a lot in common.  At their heart they embrace that a highly complex and uncertain environment requires decision making to be distributed to the team so that teams can dynamically adapt to new situations.  In old fashioned management speak we’d call this delegation and delegation requires trust.


You'd trust these guys, right!?

Lieutenant Colonel Lawrence G. Shattuck, US Army in his paper “Communicating Intent and Imparting Presence” discusses the doctrine the Commander’s Intent. In it he states:

“confidence in subordinates stems from the superior’s intimate personal knowledge of each one.”

Futhermore:

“Trust between superior and subordinate is the cornerstone of mission-oriented command.  The superior trusts his subordinate to exercise his judgment and creativity, to act as the situation dictates to reach the maximum goal articulated in his mission; the subordinate trusts that whatever action he takes in good faith to contribute to the good of the whole will be supported by his superior.”

In a software delivery context I could read this as “Get to know your team, let them do their jobs and trust that they want the best outcome.”

When I read the Manifesto for Agile Software Development I see it as a worldview based on trust.  Three of the four points listed revolve around trust.

  • Individuals and interactions over processes and tools – trust your people and keep communication flowing.
  • Working software over comprehensive documentation – trust can be built by delivering working software
  • Customer collaboration over contract negotiation – work together to build trust and empathy and contacts wont be needed as much.
Do you think Agile teams are built on trust?

In my followup article I’ll discuss how the Commander’s Intent proves that Big Upfront Design hindered successful outcomes.

Please take the time to read the full paper.

→ 4 CommentsTags:·····

Does Agile Software Development Prevent Rounded Products?

June 8th, 2011 · Agile, Agile Bench, Product Development

On Saturday the Agile Bench team attended Product Camp Sydney.  The Brainmates crew did a spectacular job getting the whole event together and promoting it so well that close to 100 people attended.  My favourite part was that everyone participated, the feeling was relaxed and most importantly, it was fun.

I was fortunate enough to rack up enough votes to speak on whether “Agile Software Development Prevent Rounded Products.”  I’ve attached the slides below but please go to the slideshare site and turn on the notes, that is where lot of the good bits are.



I also want to say thanks to Mishymash, who was attentive enough to take some great notes of my session too in mind map form (they look great, please check them out).

→ 2 CommentsTags:·······

Your workflow, your way for your agile project

June 6th, 2011 · Agile Bench, Features

We all have jobs to do.  In agile project management we call these work items stories, bugs, chores (or technical tasks), epics, features and many other variations.  Despite the range of work item names, they all locally fit into three states:

  • to do
  • in progress
  • done

The original version of Agile Bench has this encoded in it’s DNA.  This works well for small team, but as your team gets larger there is often the desire to have more fine grained control of the “in progress” state.

We’re now expanding our functionality by allowing you to change the workflow states.

You can add in new workflow states, they can be renamed at any time and best of all you can rearrange the workflow states by dragging and dropping them.  So easy!

The new workflow editor

There are a couple of things to know.  Changes to workflow states affect the whole project, not just the current iteration.  The backlog now only has the first (the to do) workflow state.  When a workflow state is deleted, all the stories in that state are moved the bottom of previous available state.  Finally, you can’t delete the first or last workflow states (you’ve got to start and end somewhere) but they can be renamed.

We have not put in the ability to restrict transitions between workflow states (such as by role).  At Agile Bench we believe this should be managed with conversation, not via a tool.

We’d love you feedback.  Do you like what were doing at the moment?

→ 1 CommentTags:·

Product Camp Sydney 2011 for Agile Product Managers and friends

May 25th, 2011 · Agile, Product Development

We love unconferences.  They are dynamic, fluid, relaxed, fun and informative.  A lot less stuffy and formal that regular conferences or user groups / meetups.

Product Camp (or PCamp for those in the know) Sydney is being held on the 4th of June at the Brainmates offices and provides a place for product professionals to share their knowledge.  In the Agile world we work with product manager in various guises – sometimes directly and sometimes through a conduit.  In a small company your Product Manager may be the CEO or head of marketing.  If you’re in a larger company you may get access to your product manager via a product owner (if you adhere to Scrum stylings), producer or a very dynamic BA.

We like the fact that all parts of the product management spectrum attend, share their knowledge, learn what works well for them and ask other participants to help them on their journey.  This is the essence of product camp – participants helping each other.  It’s great fun, with a great group of people.

Agile Bench is very proud to help sponsor PCamp Sydney.  We hope to see you there.  Please say hi!

→ No CommentsTags:·····

A Series Of Updates – Story Wall

May 15th, 2011 · Agile Bench, Product Development

We’ve been very busy at Agile Bench HQ but we’ve also been very quiet.  Over the last few months we’ve put a significant amount of effort into providing a Story Wall interface.  We’ve had many of our customers request an interface that resembles a physical story wall with cards and today we’re providing it.

Please log in or create a free project and check out the changes.

Today we just want to provide a bit of a glimpse of what we’ve been up to.  Over the next few months we’ll be rolling out more information on how we’re helping teams get their work done.  We expect the story wall will be particularly helpful for geographically distributed teams.

New Story Wall

The new interface has stories that somewhat look like cards with:

  • a story type in the top right hand corner (story, bug, chore, epic)
  • people allocated to the story (yes, more than one person can be assigned to a story) down the bottom
  • points on the bottom right hand side
  • the ability to color code your stories in any way you see fit.
  • a full drag and drop interface for moving stories, just like you would on a real story wall

The Story Wall is new so need your feedback.  Please send any thoughts on our new story wall through to us either as comments here or to me mark at agilebench dot com.

The next few months are going to be very exciting for Agile Bench.  Stay tuned.  This is going to be fun!

→ No CommentsTags:

Mark Mansour, Agile Bench CEO on Global Product Management Talk

March 15th, 2011 · Agile Bench

Is this thing on? by theilr @ flickr

The Global Product Management Talk brings international product managers together with experts in their field, weekly in a twitter chat format.  Cindy F. Solomon and Adrienne Tan (brainmates) have set up a preeminent list of speakers of which we are humbled to be a part of.

I’ll be “talking” with Cindy and Adrienne  on Monday March 21st 3-4pm (Californian time)/Tuesday March 22nd 10-11am (Sydney time).  The easiest way to follow along is to:

  • Follow @ProdMgmtTalk
  • Join in using hashtag #ProdMgmtTalk weekly at Twebevent or Tweetchat

See you online.

→ No CommentsTags: