Trying everyday to get a little better

Tips for Effective User Story Gathering Meetings

The typical approach in gathering requirements for an agile managed software or hardware development project is to first conduct user role modeling meetings.  A collection of developers, product people, marketing, subject matter experts meet to brainstorm all the different user roles that will interact with the system being created. 

After gathering the list, the next step is to generate a list of user stories.  One very effective way to do this is to conduct user story gathering sessions, where the group of project members and customers iterate through each user role, brainstorming all the ways the user will interact with the system.  Often, a paper prototype outlining a rough workflow is used or created during the session to facilitate the conversation.

Mike Cohn has done an excellent job describing both of these activities in his books Agile Estimating and Planning and User Stories Applied.  I’d like to suggest a few tips that have helped make these activities even more useful in generating requirements documentation

  • Prepare paper prototypes before the user story gathering meetings with the obvious stories.  This will give your meeting attendees a good starting point, serve as examples of how to do a prototype, and speed things along. 
  • Use Visio or Powerpoint to build your paper prototypes instead of a whiteboard or notecards.  Having an electronic copy I can pass around to distributed members of the team is very useful.  Plus I find that I am often flipping between multiple workflows during user story gathering meetings, which is hard to do if you drew everything on a whiteboard that might be already erased. 
  • Start with the user role with the largest role in the system and work your way through each user role in descending order of system interaction.  This will cause you to write up a lot of different paper prototype workflows.  As you get further down the list of roles, you will find that the paper prototypes you need to facilitate the discussion are mostly already built.  (Yet another reason to keep your workflows in an electronic format)
  • Don’t forget to gather stories for the hidden users roles!  I find it extremely useful to work through the system as the role of developer, designer, project manager, qa manager, product owner, suppler, etc.  Example stories you could generate as a project manager for a new web application project could be:
    • As a project manager I want to conduct a PCI compliance gap analysis for my planed network architecture to make it easier to attain compliance later.
    • As a developer, I want to setup a continuous integration server for the project so that our unit tests are executed regularly.

I hope you find these suggestions useful.

September 11, 2009 Posted by | Project Management, Uncategorized | , , | 2 Comments

Save Time by Checking Email on Your BlackBerry Instead of Your Computer

I’ve noticed that I can get through my email in half the time if I use my BlackBerry rather than my computer. Email using my computer takes about 3 to 4 hours of my day, so using my BlackBerry is a huge time saver.

So why is it faster to do email on my BlackBerry than a computer?

For one, firing up my Windows Vista laptop sure ain’t quick. Even coming out of sleep mode, this can take a few minutes. My BlackBerry is always on, ready to go as fast as I can reach in my pocket.

Two, I’ve got about 1.5 GB of email, and I receive about 150 emails a day, so opening Outlook can take a while. Other actions, like deleting messages, switching to the next message, etc… also take a second or two and seem to get worse as my mailbox grows over time (I know I can archive things, but I tend to use past mails every so often). Flipping to email on my BlackBerry takes about a second. Deleting multiple messages is fast and easy to do by selecting multiple messages. Opening messages is instant. Even viewing attachments is quick on my Verizon BlackBerry Curve.

Thirdly, typing on a BlackBerry is almost as fast as a computer for me. But because its a BlackBerry, I somehow feel it’s ok to much more brief in my responses… like its a text message. I make use of common acronyms like TY or IMHO (or WTF) that I wouldn’t normally do in an email I’d type out from my computer. Maybe it’s just me, but I feel like its ok to use text speak in email from a BlackBerry but not from a email created on a computer. Saves alot of typing and time!

If a particular email message requires extra attention, or a very long response, I will mark the message as not opened and take care of it from my computer later.

So maybe this approach can work for you? If you have a BlackBerry, or any smart phone with a real physical keyboard (I don’t think a touch screen keyboard will be fast enough), consider using this as your primary email device.

March 28, 2009 Posted by | Uncategorized | , , , , , , | 5 Comments

Release Web Software to Production in the Morning

Until recently, most development shops I’ve been a part of have performed software releases to production after hours, typically late at night.  The conventional thinking is that releasing off hours minimizes the risk of disrupting users if there are bugs in the release that were not found in QA or if the web site must go down during the release process. 

Over the past few months, we’ve tried something different.  We release once every 3 weeks or so.  The day before the release, the dev team works long and hard to ensure that QA is completed, all bugs are fixed and verified in QA environments.  Then we all go home, get a good nights sleep, then start the release first thing in the morning when everyone is back at work.  Our releases usually take about 45 minutes, but some can last several hours if we are pushing a lot of configuration changes.  We rarely need to bring production completely down for a release, as we can shift load and take clusters out of service using a load balancer. 

Reasons why I’ve come to really like this approach:

  • If you release at the end of the day, often times not all your development staff is around.  I’ve seen this many times where developers don’t stick around because they don’t have any code going in the release.  But, that doesn’t mean you might not need that particular developer if something goes wrong, especially if you have to rollback.
  • First thing in the morning, your development staff is fresh and ready to go.  If you release at then end of a long day, and something bad happens in production, it can be brutal to try to figure it out.  It’s like working 12 hours, then someone handing you a calculus problem.  Good luck.  The developer is much more likely to fix the issue quickly and correctly early in the day.
  • Releasing in the morning also makes it easier to observe the production environment for a time after the release.  A production issue might not be apparant right after the release, it may take an hour or two (ahem, a queue backing up).  Releasing in the morning allows development to keep an eye on production during the day and make sure everything is running smoothly.

Releasing in the morning might will not work for everyone.  If your production environment has so much load that it can’t afford part of the cluster going down, then this isn’t possible for you.  But if you can technically do it, I suggest you give it a try.  I’d love to hear back from others about their experiences with this.

February 13, 2009 Posted by | Uncategorized | , , , , , , , , , , , , , , , , , , , | 4 Comments

Achieving a Work Life Balance at an Internet Startup

To quote Luke… “You ask the impossible”. Although making your boss at work and your family at home happy may not be as difficult as lifting an x-wing fighter out of a murky Degobah swamp with nothing more than your thoughts, it is still quite the challenge.

Everyone wants more. Your family wants more of you. Your board of directories want more.  Your employees and co-workes want more.  No one is ever happy with the amount of time you are able to devote to them.

A manager at a startup should expect to work 50 to 60 hours a week.  Find an amount within that range that is sustainable, and try to stick to this.   I find that I can do 10 hours a day during the week, and 5 hours over the weekend.  So to get your hours in and be the most productive you can, try out these tips.

  • Try to do 8 hours in the office, and 2 at home during the week.  Sitting next to your spouse on the sofa in the evening allows you to multitask: spending time with the family while working.
  • Be home for bedtime.  If you have kids, make sure you are home at least 3 times a week for bedtime.  I find that I can leave work around 6pm, get my kids bathed and put to bed, eat, then get back to work.  Life is short, and you shouldn’t miss this special time of the day.
  • I like to be home at 5 on Fridays, so I will work one late night a week so that I can cut out early on Friday. 
  • Save email for later.  I find that addressing my email at night, when I’m a little tired, is a good use of my brain in a tired state.  Doing this regularly gets people used to expecting 24 hour turn around on emails, rather than immediate response.  Plus, doing email all at one time at the end of the day allows you to not get interrupted during the day. 
  • Use your time efficiently.  Eat lunch at your desk.  Get a smartphone with email.  Your drive to work is a great time to check mail.

For those times that your spouse looses their patience with you, I suggest reminding them that if building a successful business was easy, everyone would do it.

December 20, 2008 Posted by | Uncategorized | 1 Comment



Get every new post delivered to your Inbox.