Rusty Divine

Live, Love, Learn, Teach

Do you have an iteration or sprint calendar?


Does your team sometimes lose track of the important mini-milestones in your iteration? Our team has daily stand-ups and a task board, but we sometimes forgot when we were supposed to get a release ticket created or if we were promoting this week or next.

We created a simple iteration calendar and pinned it up at our stand-up wall. Each day we moved a red pin to the day we were at. It was a simple hack to help us remember to do all the little things, which was extra important on our team because each member took a turn with setting up the necessary meetings and doing the actual code promotion.

If you would like to learn more about how we managed our iterations check out module 5 of my Pluralsight course on Introduction to Working the Project.

Agile Story Pointing Benchmarks

We use story points to estimate how much effort a given story will take. We have found it reduces optimism inherent in estimating with hours because it encourages the team to use comparisons to other stories instead of imagining how long it will take. When we do estimate with hours, we typically think about the happy-path, and really, that’s OK.

Consider a two-week iteration with 10 stories. Maybe 6 of those stories take the happy-path and are completed pretty much as expected. Two stories are actually a lot easier and are completed faster than expected, but the other two take significantly longer than expected. The problem is, we don’t know which 2 those are in the beginning, so there’s no way using hours to accurately estimate. Instead, if your team is fairly consistent, you can use points to know that in a given iteration you can complete 30 points of stories. A few of those stories turn out harder than you expected, but that’s always the case. Everything evens out in the end, or at least, evens out more consistently in the end.

But, to get this ball rolling your team really needs a good common understanding about how to compare two stories to know how much bigger one is than another. We use the series of sizes like: .5, 1, 2, 3, 5, 8, 13, 20 –> we rarely let a story stay at 13 or 20 without breaking it down further because at that size we’re getting into something we’re not sure someone can complete in one iteration. You can start your team off by choosing a very familiar story that can be your 2-point benchmark, and one that can be your 5-point benchmark. Then, every story you consider can be compared to those two benchmarks and your team can collectively decide where in the range the story fits. Typically even non-developers can point development stories and developers can point non-development stories as long as they can fit it into their mental picture for how much effort a story like that would take.

Our team has experimented with taking it one step further and creating descriptions for each of these stories. This is still experimental and the general feeling is we would need to shorten this list by about half to make it more concise:

.5pt story

· Small bug fixes with no foreseeable risk and small JavaScript tweaks

· Small view updates; no tests affected (spelling; remove field; add label; move field)

· Business meeting that requires less than two hours of prep work

1pt story

· Bug fix with low-to-medium difficulty/risk, but well-understood, may affect a few tests

· Simple well-defined task (new validation; make field read-only when; fix/improve CSS)

· Research task time-boxed at about a day (what if scenario; will this work)

· Business meeting that requires two-to-six hours of prep/follow-up work

2pt story

· Bug of medium difficulty/uncertainty, or several tests affected (unexplained JS errors; AJAX)

· Understood task spanning >1 layers/screens/tables (validation rule server & client side; repetitive but tricky; significant data load script changes)

· Try small prototype (performance improvement; what if scenario)

· Business meeting that requires both significant prep and follow-up work (6-to-12 hours)

3pt story

· Bug fix of medium-high difficulty, significant uncertainty, or many tests affected (concurrency;

· Very simple screen or feature (system functions; nightly jobs action)

· Task spanning multiple layers/screens with one-or-two business rules to modify

· Significant updating of existing documentation (UCP; user manual; tech document; workflow)

· Multi-day research tasks (investigate one-to-two COBOL programs; new framework/tool)

· Business meeting requiring 2-3 meetings or >2 day research/analysis

5pt story

· Bug fix of high-difficulty, high uncertainty, and probable course changes (fix & refactor)

· Design & implement new feature, service, or framework (toast; branch-wide; JS test framework)

· Research & implement performance improvement (batch update via sproc; profiling)

· Documentation branch-wide (style guide; user manual)

· Series of 3-5 business meetings with analysis and design (pink sheet; COBOL workflow)

8pt story

· Implement a new feature that affects most/all of the site (granular security; table logging)

· Refactor a significant amount of code (funding section page, database/code renaming)

· Implement a screen from CICS (estimate adj.)

· Comprehensive documentation (site-wide user guide, technical specs)

· Significant research that will take most of the iteration for one person

13pt story

· Design & Implement an automated process/service (prod>test data move)

· Significant research task that could take all of an iteration for one or two people

20pt story (Consider if this story can be broken down into smaller stories)

· Large research task that could take an entire iteration for two-or-three people

· Very complicated refactoring

· Create and configure a new project solution (n-tier, nugget packages, tests, basic gui)

Outline for Upcoming Talk on Getting to Minimum Viable Product (MVP)

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.

7 sheets of paper * 6 mins per sheet is a great way to plan a talk. Hat-tip @shanselman, @john_papa, @pluralsightI 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"

     - greenfield

     - 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

- Questions?