On the last Saturday of March, I’ll be giving a talk at Nebraska Code Camp titled, “An Agile Requirements Gathering Process to get to MVP.” My progress will be shared here on this blog, and ultimately, the slides and maybe even a video of my presentation will be available.
The talk covers the experience Keil, Adam, and I had using a requirements gathering process we adapted. The big idea is:
An agile assessment process can help stakeholders define and agree on the vision for a project, the most important features and their priorities, and help prevent developing something that strays off target.
I want each slide in the presentation to support that idea if it can so that the message sticks. Having the one big point to make helps me determine how to prune and focus the talk.
I started out with a stack of sticky notes, each with its own thought. Next, I decided that if I divided the presentation into seven six-minute talks, plus an introduction and conclusion, then I could more easily determine how to pace the talk and define its structure. I took seven sheets of paper, and organized the sticky notes onto them.
Today I took each page and thought about the main reason for each, then created an outline with notes about the ideas I had. I started combining and separating the notes on different pages, moving them around, and identifying some I hadn’t thought of.
The outline is posted below so that Keil and Adam, or anyone really, can comment on it and help me to clarify it. I feel like I have too much content here, so using the big idea above for reference, I should be able to pull some out – for instance, talking about how to sell an assessment while handy doesn’t really support the big idea. I’ve left that in for now to help show the process.
I want to include as much showing of the process as opposed to telling about it as possible, so I am going to be walking through the assessment of an app called “Where’s the Fruit” (WTF). Adam and I have already done an assessment on this app, which we did to help show off the process to potential customers.
I’ve been using the Pomodoro technique (just the timer) while working on this presentation, and that’s really helped me focus. My next step will be to start creating the slide deck using some tips from Pluralsight (John & Scott), Scott Adams, and Rexi Media.
Part 0 - Intro
- Introduction, welcome
- Talk about what’s in it for the audience (story/reward), provoke curiosity
- brief overview
Part 1&2 - Answer Why
- Story of how we were doing things before this method. Good and bad. Ask audience if they've can relate.
- Tell me how much this project will cost after this 30min meeting; book review analogy
- There is no such thing as a simple app
- Story of how we learned about this process from someone in our peer group.
- Why it works for consulting projects
- Balance between full agile and waterfall; a middle-ground for establishing trust
- Weed out customers who won't even pay for the requirements gathering. Story of D.S..
- Client/Stakeholder empowerment through driving the requirements
- Budgeting needs
- Fixed price vs. T&M
- What does it not work well for
- "I have a problem"
- Migrating one system to another
- Integrating one system to another
- What does it work well for
- "I have an idea"
- Getting multiple stakeholders to agree on the vision and priority. Need as many stakeholders in the room as possible, and devs, too, so they can get in on the vision from the ground floor.
- Getting the core feature set determined (aka mvp)
Part 3 - Selling & Preparation
- Simple to sell a fixed-price product vs a T&M project
- This process, or something like it, is something we have to do anyway. We're just pulling it out and putting it in front.
- Gives customer a chance to work with us with a small risk
- At the end of the assessment, they can take it and shop it around or continue with us
- We don't validate the business idea, but could give them some feed back as a SWOT
- Consider having a plan for handling conflict between stakeholders and practicing.
- To prepare
- Send customer information about the process and what to bring and what to expect. The more work they put in up front, the better.
- Setup the room, preferably one that is very large and has a large white board or two or wall board paint
- Put the agenda and rules up
- refreshments and name cards ready
- sticky notes for story titles
- One note taker, one facilitator
- Try to do between meals
Part 4 - Getting Started
- We are going to walk through a mock product - where's the fruit
- We don’t know the budget or schedule, customers don’t like to tell us that up front (trust)
- Talk through the agenda
- Never feels like enough time, but we make due
- Define the objective
- what makes a good objective
- SMART, derived from narrative, like an epoch; could have a so that
- edit it as needed throughout the day
- WTF's objective revealed and dissected
- Users and Roles
- Admin users
- end users of different types (don't get too stuck on these)
- system integrations
- report users
- these become the actors in the user stories and can provide a check point during the meeting to see if we've captured the main stories for each user
Part 5 - User Stories
- User stories format
- format of a user story
- why the so that is so important
- look out for circular reasoning
- conditions of acceptance
- consider admin tasks; back-end user & data management
- consider the long haul; archiving, cleaning, moderating, reporting
- have customer describe the workflow they envision as if they were sitting down to use the app
- easy to overlook stories about security, exports, logging, reporting - some of these can be added in after the assessment during the research
- User story examples
- WTF's examples
- Get the audience to throw one out
- Write down constraints and assumptions as they come out
- show WTF's examples
- Diagram and mockup as necessary, but beware of spending a lot of time there
Part 6 - Defining the core feature set
- Good time for a break to get people's mind a rest
- Put all the sticky notes of feature titles onto the wall
- Have stakeholders take turns organizing them into what is most important first
- guidance is needed to give them context
- Importance does not equal darling
- Which feature is more important than another in context of having a functioning application
- Can't put stories at the same level; can nest them if they really are related, but otherwise have to decide if one of these stories wouldn't get done, which one would I rather get done
- After everyone is satisfied, it's time to draw the core feature set line
- Sometimes this is hard for customers who want it all
- We need to determine what has to be there for the system to stand up on its own
- We can and should add more later; priorities will shift, new ideas gained, old ones discarded.
- What we find is the target has moved by the time we get that small set finished, so aiming to do more than that will often waste time, effort, money.
- That's a wrap. Now, we're all exhausted and don't plan on doing anything else productive.
- One more thing to do - a meeting retro. We did this without the customers sometimes and with them sometimes.
Part 7 - Post Assessment
- Off-the-shelf research - is anyone else already doing this; can we integrate?
- How we point stories
- filling in any missing stories
- Assembling deliverable
- creating some mockups, workflow sketches
- tools: PowerPoint w/mockups,
- lean canvas and/or SWOT
- Proposal with fixed price, first available start date, stories and their sizes down to CFS
- project scope & price is more about sum of user points; customer can swap in/out stories as long as total points are same
- how to convert points to dollars
- Running a project
- two-week iterations, burn down, daily stand up with customer, demo/retro, customer prioritizes and manages scope, change requests
- You can use this process for your own ideas, or for customers
- It is a great way to brainstorm features, get agreement among stake holders, and get everyone in the room on the same vision
- Get the slides and more information from my blog, and feel free to contact me