[et_pb_section][et_pb_row][et_pb_column][et_pb_text]<\/p>\n
As the Managing Partner at MB&A \u2013 which specializes in data collection, inspection, and assessment products built on the Salesforce platform \u2013 let me come right out and say that Agile is awesome. Even so, we\u2019ve modified the standard processes to meet our needs, evolving priorities, and work culture. That\u2019s because, in my 25 years of experience in technology, I\u2019ve come to realize that \u201cbest practice\u201d is what everyone agrees is the right approach, whereas \u201cgood practice\u201d is what works for your team and organization. We aspire to take the best<\/em> of \u201cbest practice\u201d and then shape it to meet our needs \u2013 something that we have come to refer to as the \u201cMB&A way.\u201d<\/p>\n 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<\/em> we\u2019re building for, what<\/em> is being built, and its overall business value \u2013 all in a concise statement:<\/p>\n As a ____________ I want to ______________, so that I can _______________.<\/em><\/strong><\/p>\n Story pointing has helped us to move away from the painstaking process of predicting hours to focus on:<\/p>\n At the risk of offending Agile zealots, my team\u2019s next step is to convert the following points into rough timelines:<\/p>\n Quite simply, we write stories and apply points to determine how much effort a project will require.<\/p>\n 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\u2019t considered, so our aim is to ensure that 80% of the finished product is represented from the beginning.<\/p>\n 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.<\/p>\n Knowing that a sprint\/story composition will change over time, it\u2019s vital to track progress. For this, we deliver a weekly report to all of our customers that indicates the stories we\u2019ve completed during previous sprints, the status of the current sprint, the allocated time for the remaining stories and future sprints, and any backlogged items.<\/p>\n 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.<\/p>\n 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 \u201cchanging\u201d becomes \u201cadding\u201d then we need to discuss change orders. In principle, we don\u2019t care whether our customers are changing things or adding as long as it doesn\u2019t materially impact the level of effort required to perform the work.<\/p>\n 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\u2019t anticipate from the beginning or that became less important.<\/p>\n Because the report is part of the process we use to execute the work, there\u2019s 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<\/em> time a new idea comes up, you prevent that idea from becoming a de facto requirement that is expected<\/em>. This has the added advantage of making customers happy, because you don\u2019t miss anything and you make it easy to tee up future projects and change order conversations.<\/p>\n Clearly, our Agile approach is a departure from best practice, but it works for us. By taking the best from \u201cbest practice,\u201d we molded it to the realities of our business and our customers\u2019 needs. In the end, MB&A required a process that could span our entire business \u2013 including managing projects in a way that ensured our customers were well-informed and that we are always on the same page.<\/p>\n 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 \u2013 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.<\/p>\nBuilding Stories<\/h2>\n
Story Pointing<\/h2>\n
\n
\n
Estimating Work<\/h2>\n
Managing Stories and Sprints<\/h2>\n
Conclusion<\/h2>\n