Working with organizations transitioning to agile I often find that estimating is one of the first areas of discomfort, and story point estimating is just too hard to grok for most. After all, most developers have been giving estimates based on time for most of their careers, and we come along and ask them to think of relative points for estimating. It often goes over like a lead balloon.

Relative T-Shirt sizing

To ease the transition I use physical aids. T-shirts to be exact. Raiding my closet for shirts of various sizes, I bring them out on estimating day and lay them on the table in front of us. Remember, this initial story sizing happens to gauge the general size of the effort to help product owners with sprint planning.

Sizes range from Small, Medium, Large, XL, and XXL. For the small, I ask the team to consider the smallest amount of work that could be accomplished in one Sprint. Don’t fret over breaking down the story into parts, that comes later in Sprint planning. Just consider the work required to complete this one piece of functionality and that gets an estimate of small.

Next consider work that is larger than small, but not quite considered large. Then medium to large, etc. It’s a relative comparison between each sizing.

Medium to Large relative sizing

With the other sizes in plain view, the team can make mental comparisons between the work required from a small to an XXL. Each sizing from small to XL represent stories that can be completed in one sprint. The stories for XXL, well, they’re just too large to effectively estimate. I tell them to consider these the major pieces that need attention by the BA or product owner to break down.

As the team gets used to the relative sizing, I’ll ask them what they are considering for the small – is this like a one day effort? What does the medium feel like – less than a week? This is a transition activity, and I’ve found that a nice give-and-take discussion around the sizing helps us move along.

With a little visual aid the teams quickly move on to estimating the work using the relative sizing concept. Not to mention they have a lot of fun calling out ‘medium’ or ‘large’ rather than abstract story point numbers.

Now, if you’re a project manager or scrum master that needs to project a schedule of relative effort in terms of time, and management does not want to wait for a couple of sprints to pass so you can measure velocity, you have the option of producing a rough (I emphasize rough), straw-man schedule based on these t-shirt sizes.

Relative to time estimates

For this I’ll take the feedback from the team on the relative sizing. If they said small was less than a day’s effort, and medium was less than a week’s effort, then that’s what I’ll use in translating the relative estimates to a project duration projection.

In this case you’ll see the XXL t-shirt is not translated into any size since this was un-estimatable in its current form. The teams I’ve worked with had a much better time estimating from sizes with the rough translation into time than just straight story point estimates or time estimates on the stories.

As I left a client site and took my shirts with me, I observed the existing project manager gather up t-shirts to continue to use with the teams for estimating. Here’s wishing your good ideas carry on as well!

1. Daily stand up meetings. Those short meetings where every team member stands in a circle and reports on what they’re working on and what roadblocks they are encountering. Getting everyone together once a day to share what they’re working on and what roadblocks are in their way is a great way to begin to build an Agile team.
2. Agile board. Posting the story cards in a visible location and enforcing the status indicators (yellow, green or red adhesive dots) is a powerful tool in raising the team’s awareness of the weekly schedule and progress.
3. Team Planning Sessions. Planning as a team is a powerful productivity tool. As the developers, business analysts, and product managers gather together and discuss the goals for the iteration and the ensuing tasks, the team takes ownership of the project plan instead of the lone project manager. With the team’s commitment to the plan, the project manager now can work for the team by removing roadblocks and providing support as needed.

That’s right, the key items are focused around forming teams. In an Agile environment it is the team that builds success. The best way to begin to see the impact of Agile is to start forming, empowering, and supporting teams.

What convinces me about these 3 simple steps is that I’ve seem these work in non-Agile organizations – and have seen first-hand the benefits of teamwork. We’ve known this for years in project management, with organizations focusing on team building exercises and excursions, team guidelines, and the like. It is that Agile takes these principles and provides a framework in which to consistently apply them. Simple concepts like team members sitting together, all the time, not just during critical project junctures; team planning, all the time; daily team communication, all the time.

It’s one of the things I like best about working with clients, helping to set up the structures for teams and seeing the teams form and grow. Kind of like gardening, where with the right materials and environment wonderful things can grow! Maybe that’s why I also like gardening so much

I was thrilled to be asked to help run a workshop for this group as they tackled such thorny issues as revisiting their purpose and goals and refining the roles and responsibilities of the LDFA and their biggest supplier, Spark. Bringing in an outside facilitator enabled every board member to participate equally without concerns of bias or prior knowledge affecting the discussion. Geting the group to come together on ideas and plans was a key goal of mine, and the chairman of the board.

My plan was to start with a process to ensure everyone’s voice was heard. The LDFA has 9 official members and 3 ex-officio members. Anyone who’s worked with groups knows that the larger the group gets, the greater the impact of group dynamics – where quiet or more reserved folks tend not to share their thoughts as much as less reserved members. So while my intentions were to begin to pair members together to address issues (which has the additional benefit of increasing familiarity of the members and building trust), the public meeting rules requried that all discussions must take place in the open and heard by all.

A modest adjustment to this model had every member write down their thoughts on 3×5 sticky notes and one-by-one share their written notes and ideas with the group. These notes were then posted on a flip chart on the wall – capturing all members ideas in one space. As each member shared their notes with the group, the group asked questions for clarification. This portion of the workshop went very well. Diverse and broad ideas were presented and shared with the group.

These ideas were quickly consolidated by the board chair and a few members while the rest took a much needed break. The remainder of the workshop benefitted from the openness of the first exercise. While the structure reverted to a more traditional board meeting – dialog among the members – the tone and nature of the dialog gradually moved away from strained to more collaborative. Thes discussions were focused back on the identified purposes, which worked to guide the group’s deliberations. By the end of the session, tough questions were asked and answered, building a foundation for increased trust among the board members.

With the facilitated aid of a few structured exercises, meetings that are subject to the Roberts Rules structure and public scrutiny can be collaborative and engaging.

This post is password protected. To view it please enter your password below:

Password:

Keep these three steps in mind for your user stories:
1. SSMART
2. User Centric
3. Independent
1. SSMART
No, that’s not a typo. Like your goals, user stories should follow the same principles, plus one, Simple;
S – Simple. The user story should be a simple item of work, not a complex series of activities. This is the heart of breaking a complex piece of work down into a number of simpler pieces that can be accomplished within the chosen iteration length. For example, a user story of ‘write and send next eZine article.’ is too vague, non specific, and feels complex due to its lack of specificity and simplicity.
S – Specific. Your user story should be specific about what is to be done. An example is: ‘Write up 2nd eZine article, format it using same template as 1st article, and ready it for distribution by selecting a target mailing list.’ This describes what is to be done, and provides enough information to begin work on the task. Note how this also defines done for the user story.
M – Measurable. Once you’ve written the user story, be sure your project team estimates the effort. Whether you use story points, hours, or some other estimation value, the act of estimating the user story will help vet the SSMART items and begin to open the discussion within the team about the scope and intent of the work.
A – Attainable. Ok, we have to actually be able to accomplish the task involved in the user story. By doing this we also support the definition of done.  So writing a user story of ‘Achieve world peace’ is a worthy goal, but not very attainable for most project teams.
R – Realistic. Like being able to accomplish the user story, it needs to be achievable by your project team. Setting a user story that is far out of their reach will not foster success. There is more that can be said of exploratory user stories, and how to treat them and use them within a project. However, the bulk of a project’s user stories should be realistic and achievable by the project team.
T – Timely. The user story should be achievable within the iteration time frame, and have a time frame associated with it. This supports the Measurable aspect of the SSMART principle.
2. USER CENTRIC
User Stories are written from the user’s point of view and tell the story of what is to be completed.  While this sounds obvious, it remains a difficult area for companies transitioning from Waterfall to Agile. A key concept for the project team is to clearly define WHO the primary user of the site is. If you design for everyone, it will be usable by no one. You can get a quick overview of persona’s on Wikipedia, which will reference much of Alan Cooper’s work . An example of a user-centric story aimed at the primary persona for the site is: ‘Jane Doe can upload her resume to the website, as well as provide up to 3 meta-tags for searching and up to 3 external links.’
3. INDEPENDENT
Often overlooked, the success of Agile user stories is the ability to replan and reschedule the user stories as business needs change. Each user story should be as independent as possible to avoid entire blocks of user stories that must be completed together. This is one of the hallmarks of Agile, and one of the pieces that teams struggle with as they try to simplify and break down a complex task into multiple pieces.
Think broadly here, and consider using techniques like stubbing out database connections so a user story that depends on a database being created can still be completed independent of the database, and integrated later when the underlying structures are set up.

User Story Samples
Following are some sample user stories that I’ve used as a Project Manager that help illustrate some of the points in the article. Notice the green status dot showing that task has been completed.

Currently I use iCal on my MacBook as my primary desktop calendar. I synchronize it to Google calendar via BusySync. I have multiple Google calendars, home, business, and social group. These all sync between my MacBook and Google. I do provide some sharing of my Google calendars.

Now, to get the calendar and contact information from my MacBook to my Windows handheld device (Motorola Q) I primarily use Mark/Space. However, there are some limitations:

• The sync must be initiated via Bluetooth connection on ActiveSync on handheld. Because Bluetooth sucks up my phone’s battery so much, I do not leave it on. So the sync starts with turning Bluetooth on, connecting with my MacBook, then starting ActiveSync via a Bluetooth connection to Mark/Space on the MacBook
• If I have run the browser from the handheld the connection doesn’t take the first time. I must reboot the handheld, which because it’s a Window’s device takes about 3 minutes to shut off and restart, then initiate the Bluetooth service, then start ActiveSync
• I can control where files come from on the MacBook; and this is my primary way to get files loaded nicely on the Motorola Q
• Interestingly enough, I can connect the Motorola Q to my MacBook via Bluetooth, treating it as a drive, and easily move pictures from the phone to the Mac. This is my preferred way to get pictures off my phone. Hmm, I should try it to get files ON my phone….

The second way to synchronize my handheld with my MacBook iCal is Google calendar’s Goosync. Notes on this are:

• It must be initiated on handheld by running Goosync
• It does operate over Internet- no Bluetooth connection needed. This alone saves me a step and potentially a lot of time since I don’t have to reboot the phone if I’ve run the browser.
• This can be automated by upgrading to the Premium account at 19.95£ annually
• The free version only does calendar syncing. To sync contacts I need to upgrade to the Premium account and spend the 19.95£ annually.

The social network Plaxo provides a synchronizing service between Google’s calendar, iCal, and Windows mobile devices. The Google calendar is free. Synchronizing to the Windows mobile device costs $49.95 a year – a bit steep for me. However, Plaxo’s calendar display is VERY NICE. The Upcoming tab has the best user interaction of all the calendaring tools I’ve used. See screen shot below. You see a three-week block view with clickable events to view the full text. Being a visual person, I like seeing the information in block form.
The most useful tool, however, is the information of what is coming up next. I get a gentle countdown of what appointments are coming up TODAY in the top part of the window, a view of what tomorrow’s appointments are in list form, and countdown to my own birthday (yeah!) as default, ability to add others, and the weather for my area today and tomorrow. The screen shows enough white space to make the calendar easy to read while providing all the information.

Mobile Me does not sync to Motorola Q. Only iPhone/iTouch and PC’s and Mac’s and of course the mobile.me website

In summary, I’m seeing more and more people using Google calendars as either a primary or a holding place, sharing them between families and social groups, and work project teams, and synchronizing these to their handhelds and desktops. The synchronizing tool is more based on what desktop and phone device they have (Mobile Me for iPhone/iTouch, GooSync, Mark/Space, Plaxo, and Blackberry sync tools for others). How are you keeping yourself synchronized?

I had basically two key projects to interleave, the graduation party preparations and the tasks of running my business. I started with creating a list of all the things I needed to do for the graduation party – see the below picture. As you’ll see, I made some attempt to assign dates to items to pace out the effort, and even began estimating how long it would take to do a particular task. The task list became unwieldy as soon as I wrote it. Immediately I wanted to move things around and see how well I could actually accomplish all this in the time allotted.

The second project of running my business would certainly impact my ability to get everything done for the graduation party. I now needed to task out the business project, and merge the two.

Creating the Plan

As you may know, I believe in keeping things simple and open to change using Agile-based tools. For the business efforts, I wrote down the item on a 3×5 card and estimated the effort it would take to complete it. I then laid these out on a day-by-day basis – creating my work plan for the business, as shown below.

Likewise, I began transcribing all the tasks from the grad party list onto either 3×5 cards or sticky notes, estimated them, and began interleaving them with the business layout such that each day was evenly loaded with effort. These were placed on 8×10 sheets of paper, where each sheet of paper represented a day, or one iteration. I now had a work plan for both projects.

Replanning
At the end of every day I would evaluate what got completed, as indicated by a green check mark, and what needed to move. Because as we all know, not everything goes as planned! Life happens, business needs change. Each day I got to re-evaluate what was key and what wasn’t. The daily review allowed me to re-prioritize the efforts to ensure that the key items would get completed, allowing less critical items to move to the bottom of the list.

Additionally, I found that some items, like Thursday’s ‘Purchase last minute items’ was complete enough to take to the grocery store and use as a shopping list. The tasks were more than just reminders, they were actionable items.

Team Involvement
I started to share with my family the tasks needed to be completed for the party by referring to these plans, and leaving them in a common space. The plan became visible.

Then a magical thing started to happen. My family not only started asking ‘what is on the plan that we need to do today?’, but they started looking at the plan themselves. They had begun to buy into the system, and take as much ownership as me on the efforts for the party. Sure, I could have just given them a task list, but I would much rather they buy into the effort on their own. Isn’t this what we want of our work teams? To be so engaged with the effort that they volunteer to work on items, and look for the next thing to do?

Yes, the party went off without a hitch. I even had enough time during the week to throw in some unplanned items, like handling last-minute business needs. Sunday came and I was not stressed out, everything that needed to be done was done without the usual last minute running-around and rushed feeling.

Wouldn’t it be nice to have this happen for all our projects? It can. Try these simple Agile project management techniques for your next project, and see the difference yourself.

Nothing in my life had changed that would account for the extra steps. Nothing except the act of measuring.

A year ago I started Weight Watchers to lose some excess pounds. For those unfamiliar with their points method, you track and log each food item that you eat and subtract it from your daily allotment.  This gives you an on-going tally of how much food you can eat for the day. These are kept in a weekly tally, so you can see how you’re doing going over or staying within the alloted points for an entire week. While I have successfully shed those extra pounds (24 of ‘em) over the past year, I continue to monitor and log my daily and weekly points. Why?

The answer lies in the act of measuring and the impact it has on what you are measuring, and specifically on the behavioral impact of measurement. By measuring something you inherently focus on it, and improve it, even if the improvement is at a subconscious level. 

And what happens when you stop measuring those things, having successfully improved them? Don’t they go back to their original sub-optimal state? Why do so many dieters gain back the weight they lost? I venture that one reason is the loss of constant measurement and its impact on behavior. 

The act of measuring leads to a continuous improvement loop.  

Hmmm, so isn’t this true for Project Management as well? We improve those things we measure. Whether it is our estimates, our time to complete, the number of hours remaining, the number of tasks to complete. By measuring and tracking we tell our teams what is important to the project and its success. However, when we stop measuring, the items so often go back to their unimproved state. 

Well, we can’t possibly measure everything all the time! We must chose wisely those items that we want to continuously improve. Which has me thinking more about Kaizen and it’s influence on the cycle of measuring and improving a process or operation. What if projects were thought of as a way to continuously improve the process, rather than just meet that deadline or produce that widget? Wouldn’t the projects be considered far more successful in terms of value to the organization and ROI? 

Well, I’m up to 3,800 steps for today, I think I’ll go for a walk and think more about project Kaizen. I’d love to hear your thoughts on this as well. Post your comments to this blog.

 

 

Their most obvious issue was that their Story Cards were not on cards at all, they were documents stored on their corporate Sharepoint site. By that very nature, they were able to write as much extraneous information as they could type. Remember, they were moving from a traditional waterfall process, so many of their business analysts and project managers were used to formal requirements documents. The new user stories as they called them became amalgamations of requirements, functional specifications, ideas, and anything else anyone said about the user story. Being stripped of their traditional documents the teams were morphing the Story Cards into a catch-all for the functions.  No wonder they were having trouble with estimating and planning!

What to do?
I started with first providing training on user stories to their Business Analysts and ScrumMasters. The sessions were geared to focus on their specific issues with user story writing. Examples of good and poor Story Cards were provided, as well as hands-on experience with writing Story Cards. Real-life examples were pulled from their Sharepoint site for examination during the training sessions, and used as discussion points for reworking their existing User Stories into better formed Story Cards.

Light Bulb Effect
One of the most notable items I observed there was the impact of business analysis practices in an Agile environment. Any deficiency existing in business analysis practices or skills among the Business Analysts becomes highlighted in an Agile environment. When writing Story Cards, the Business Analyst must produce a clear and concise picture of the value of the task to the end-user. This story covers describing the setting in which the end-user would be performing the work, the Why, along with Who will perform it, and When it would be done by the end-user. I call this the Light Bulb Effect – when the spark of an insight or idea occurs to the Business Analyst and this is transferred to the development team by way of a well written Story Card.

During the annual work holiday party at our house this weekend (yes we know it’s well past the holidays) I experienced some awesome and unconventional team building. My teenage sons ran out and purchased Rock Band for our Xbox 360 system and set it up during the party. Suddenly we had 4 people of varying ages and backgrounds playing and singing together.

The basic premise of this game is to live your alter-ego and play a pseudo-musical instrument and sound reasonably well. Hooked up to your TV (the larger the screen the better!) you see your colored symbols for notes stream towards you, while the accompanying music of the song plays in the background. If you miss a note, a slight off-pitch note plays, if you hit the note, the song plays as normal.

Unlike similar games such as Guitar Hero, your goal is to play with others as a team. A guitar, bass, drums and singer can all join in together for each song. Each player can play at their level of experience; Easy, Medium, Hard, Expert. But each player can fail if they miss enough notes. If a player fails, they increase the risk of the entire band failing the song – which ends quite abruptly among clanking sounds and boos from the virtual audience – not to mention the abuse from their physical band mates! Each team member has the incentive to play well to not only stay in the game themselves but to keep the band going and succeed.

So, during this evening of physics nerds, spouses, friends, and children at our house, I saw frequent examples of others stepping up to save the failed player. How does a simple computer-based game bring such diverse people physically together to achieve a single goal – where all the office ‘team building’ seminars continually miss the boat? My thoughts on this are:

First, the game appeals to a wide range of people. It’s rock & roll after all, using tools that are familiar to many of us – guitars, drums, a microphone. To play is simple – you need only a small amount of instruction before you’re rocking with the rest of the band.

Second, the physical nature of the game ties into our human nature of binding together in person. You’re sitting together in the same room, and if you’re lucky, you may have others watching you play as well. Which leads me to #3…

Third, you’re up on stage, both virtually on the TV screen, and physically in the room, while others can, and will, watch you. Who doesn’t enjoy being admired by others???!!

Fourth – it’s just plain FUN!! No wierd exercises or quirky exercises to complete – you just start playing and having fun right away!

In short, the next time your team needs a kick start for some team remediation, use Rock Band and you just might actually have some fun!

ps – anyone willing to get a Rock Band jam going at an Ann Arbor business, let me know. I’ll bring my own guitar!