Detailed Story Narrative




  • Avatar
    Suzie Prince


    I am obviously missing a lot of detail about this situation and your stories but I have two simple suggestions.

    1. Encourage your developers to talk to you about the requirements. The story is a placeholder for a conversation and what it contains should be your/customers notes about what they want. I have had a lot of success by asking developers to just talk with me about the story before implementing it instead of reading the card. I have found that a good discussion between team members will resolve any confusion and result in a better and common understanding than a well written story.

    2. (I know that there are often reasons why a conversation may not be possible. I have worked on distributed teams etc...) Use bullet points and bolding or tables to highlight the difference between function and actuals.

    A couple of examples:


    • Add a new section to Page ABC

      • This should be called "XYZ"


    Page New Section Title
    ABC  XYZ

    I hope that this helps.


    - Suzie





    Comment actions Permalink
  • Avatar
    Michael Green

    Hi Fitch,

     I'll +1 Suzie's suggestions... functional folks need MUST talk to your devs!  Here are a few things we recently changed when we nearly doubled our team size (other than trying to figure out how to break them into two logical teams....but thats another post)....

    Instituted process.  we all hate process, especially devs that have been working in more flexible/lacking process teams.  Its agile, not cowboy coding - a flowchart of your development cycle still has a place (but use balsamiq or simplydiagrams, vs big-evil-visio!) part of the process we have a gate that for a dev to start working on a card, they have to talk to the author or BA that is familiar with the card.  I like to have the developer tell me, in plain english and not reading the card, what they think the spirit/purpose of the card is.   Nearly every time we have this brief IM chat or verbal conversation, we make a tweak to the card for the good.

    So, to solve your specific problem here, I'd recommend doing the above with your devs so that they understand what page your adding and what its called.  If they want that as a specific requirement written down, either fire them or move them to a waterfall project. 

    I say this because an agile team cant be about "its not in the rules section so I didnt code it" or "it wasnt on the card, I knew it was supposed to be there, but I didnt do it" (the same way the functional folks cant blame devs, but thats another post).  You need to create a team that is eager to make a working application - not just satisfy written requirements on a card.  If you have that type of team, you need to change that (either by changing the people or, well, changing-out the people).


    The other process step we added, that might help with your issue, is to add a few little dev steps BEFORE they set the card ready for testing (or done, ready for CI, ready for QA or whatever your steps may be).
    First, have what you developed and the card in front of you (two monitors, or print it out... we actually forced some folks to print it out) and read it, line by line, and make sure you addressed everything. In a card with 10 if/then rules, make sure they all got done.  Look at the stuff like your example above -

    • Create a new section called XYZ on the ABC page

    and make sure there is, in fact, a section called XYZ on the ABC page.  seems silly to miss that, but a final read-thru seems to catch these "ohhh, didnt see that" type stuff.

    Bottom line - I wouldnt create a table or repeat the info.   Make the developer understand the task and desire to make it a successful card the first go 'round.






    Comment actions Permalink

Please sign in to leave a comment.