As the Managing Partner at MB&A – which specializes in data collection, inspection, and assessment products built on the Salesforce platform – let me come right out and say that Agile is awesome. Even so, we’ve modified the standard processes to meet our needs, evolving priorities, and work culture. That’s because, in my 25 years of experience in technology, I’ve come to realize that “best practice” is what everyone agrees is the right approach, whereas “good practice” is what works for your team and organization. We aspire to take the best of “best practice” and then shape it to meet our needs – something that we have come to refer to as the “MB&A way.”
Building Stories
When it comes to creating stories, story pointing, selecting appropriate meeting formats, and cadence, our Agile implementation is true to form. The story approach is particularly useful insofar as it forces us to think through who we’re building for, what is being built, and its overall business value – all in a concise statement:
As a ____________ I want to ______________, so that I can _______________.
Story Pointing
Story pointing has helped us to move away from the painstaking process of predicting hours to focus on:
- Technical complexity – complex work items often take longer and require more effort
- Resource complexity – work items that require a depth and breadth of skills tend to involve more coordination, timelines, and resources to execute
- What we know – ideas that are well-defined are easier to work with
At the risk of offending Agile zealots, my team’s next step is to convert the following points into rough timelines:
- 1pt – This is easy and I’ll have it done in less than an hour.
- 2pts – It’s pretty easy. I may have to talk to someone, look something up, or put in a bit more effort, but – once I get rolling – it’ll only take a couple of hours to complete.
- 3pts – Since I’ve done this before/know how it works, it shouldn’t take longer than a half-day to deliver (with some coordination).
- 5pts – This is pretty straightforward. It may require some coordination, research, or dedicated time to finish, but I’m confident this can be done in a half-day to a day.
- 8pts – This requires either a decent chunk of “heads down” work or coordination, investigation, and research that should take a little over one day.
- 13pts – Considering the project scope, it’s going to take a few days of dedicated work and there may be some dependencies (coordination or research). It may also end up spawning other stories.
- 21pts – While this story should have been further decomposed, we estimated it to the best of our abilities with the information we had in the beginning. This story may take a week and is highly likely to spawn other stories, involve more research, further requirement derivation, and a host of other things that introduce risk into the process or project.
Estimating Work
Quite simply, we write stories and apply points to determine how much effort a project will require.
As a team, we come up with a full set of stories to describe the finished product. Of course, the stories may generate additional branches that we hadn’t considered, so our aim is to ensure that 80% of the finished product is represented from the beginning.
Next, we decompose the stories into a series of two-week sprints. We recommend that our customers not extend themselves beyond 4-6 sprints for the sake of fidelity and accuracy. Granted, due to contractual requirements with larger (or public sector) organizations, we are sometimes required to move beyond that level.
Managing Stories and Sprints
Knowing that a sprint/story composition will change over time, it’s vital to track progress. For this, we deliver a weekly report to all of our customers that indicates the stories we’ve completed during previous sprints, the status of the current sprint, the allocated time for the remaining stories and future sprints, and any backlogged items.
To give a high-level overview, we also show the story pointing that was expected in the initial planning stage (i.e., the initial sprint points) and the current sprint points. Having all of this in one report makes it easy for customers to understand where they are in the project from week to week and the total effort that will be required to get everything they want to the finish line.
Not only does this report help our customers (internal or external to understand what was bid/estimated vs. what really happened, it helps us to facilitate the substitution vs. change order conversation. Even though we are always up front and willing to evolve our efforts, when “changing” becomes “adding” then we need to discuss change orders. In principle, we don’t care whether our customers are changing things or adding as long as it doesn’t materially impact the level of effort required to perform the work.
This is where story pointing comes in particularly handy. It helps us to show our customers how evolving requirements can either be supported by substituting stories with similar numbers of points, or where adding requires additional sprints (and perhaps additional work to reach the finish line). Whenever an item is left up in the air, we put the story in the backlog with the stuff we didn’t anticipate from the beginning or that became less important.
Because the report is part of the process we use to execute the work, there’s very little overhead required to manage the project or reporting. It also helps us to streamline administration and customer inquiries. By taking a few minutes to add a story every time a new idea comes up, you prevent that idea from becoming a de facto requirement that is expected. This has the added advantage of making customers happy, because you don’t miss anything and you make it easy to tee up future projects and change order conversations.
Conclusion
Clearly, our Agile approach is a departure from best practice, but it works for us. By taking the best from “best practice,” we molded it to the realities of our business and our customers’ needs. In the end, MB&A required a process that could span our entire business – including managing projects in a way that ensured our customers were well-informed and that we are always on the same page.
The early issues we confronted using Agile were related to scope creep and costs. Although we delivered great projects, we often found ourselves in difficult conversations – ones that could have been avoided if we had done a better job of setting expectations and managing them as projects evolved. Because the internally focused parts of our work (i.e., stories, sprints, and points) always met our targets, we needed to invest the time and effort in making it work for our customers. I hope this post helps you to do the same.
