Agile seems like a mystery to many. It has an unfamiliar vocabulary and practices. To outsiders, it feels like an exclusive club. However, when we step back and inspect agile, we see that it follows common, recognizable patterns from our daily lives.
Imagine it is Thursday evening. Your family is planning the upcoming weekend. There is a fixed amount of time and many things to do. This is the classic project management challenge. Let’s explore how agile practices can be applied to this common predicament.
Time-Boxing
Time-boxing is allocating a set amount of time to an activity and then sticking to that constraint. Our weekend is time boxed. It is two days long, with a hard stop on Monday morning.
The children’s soccer game is time boxed. Games are split into timed halves with a running clock. Baseball games are not time boxed. They are nine innings and can seemingly go on forever.
Agile ceremonies (meetings) are time-boxed, which creates focus and a sense of urgency. Development is also time boxed. Teams deliver small increments of value in each 2-week iteration (or sprint).
Progressive Elaboration
Progressive elaboration is a standard project management practice. It recognizes that we cannot possibly plan everything up front, so we keep the future in mind and plan our upcoming work at the appropriate level of detail. Not over-planning saves effort and lets us adjust more quickly.
The family calendar is its planning roadmap. Events are placed on the calendar when known, and details are planned as needed. For example, when we receive the “save the date” postcard for our friend’s destination wedding, we put it on the calendar (roadmap). Then, travel arrangements are made at the appropriate time. Book the refundable hotel room early. Start tracking airfares to get the best price.
Product Backlog
The product backlog is a prioritized list of everything that needs to be done. This includes all the customer-facing features and technical updates required to enhance or maintain the product. The product backlog is similar to our running list of chores.
Our family to-do list is prioritized. Going to the grocery store is required, while the farmers market is desired but optional. Defrosting the basement freezer has been at the bottom of the list for months.
The product backlog is emergent, meaning items can be added, removed, or reprioritized. The last-minute invite is added. Fixing the dripping sink that is now a steady stream is moved up the list. Sending your great-aunt, a birthday card is dropped because you already forgot her birthday.
User Stories
Instead of requirements, we employ user stories to explain what is needed. There are feature stories that describe who want something, why they want it, and the expected benefit. Feature stories are intended to generate a conversation about the best solution. Enabler stories define the capabilities needed to support the features. Large or complex stories may be refined or broken down into smaller, more well-defined ones.
Our family may have a feature story to repaint a child’s bedroom, which will spark many discussions. It may also spawn other features, such as replacing bedding, window treatments, and artwork. There will be several enablers, such as purchasing supplies, prepping the walls, painting the room, and cleaning up. Breaking up the work makes it more manageable and more likely to be accomplished.
Story Sizing
We use story points to estimate work size and complexity instead of hours. Relative sizing tools, like t-shirt sizing, are generally reasonable and more accurate than duration estimates. The non-linear Fibonacci sequence (1, 2, 3, 5, 8, & 13) is often used because it reflects that uncertainty increases as work items get bigger.
Changing the lamp lightbulb may be a 1, while changing the elaborate overhead fixture may be a 2 or 3. Going shopping at Home Depot, which always takes longer than expected, is an 8, while the local hardware store may be a 5.
Story points are used to estimate each backlog item’s size and the team’s velocity. Velocity is the number of stories story points a team completes in a given unit of time, which becomes the basis for estimating the team’s capacity—how much work can be completed in each iteration.
We use similar practices when planning our weekend activities. Rather than estimating the hours it will take to do something, we consider roughly how big it is compared to something else.
Iteration Planning
Iteration planning is a time-boxed meeting held at the beginning of the sprint. First, the team and the product owner review the items on the product backlog. Then, they use story points to size the work, estimate their capacity, and figure out what they plan to accomplish.
Items are moved from the product backlog to the iteration backlog until the capacity has been filled. The iteration backlog is the committed to-do list. Imagine filling a bucket with rocks. First go the big rocks, then the smaller ones, and finally, sprinkle in the pebbles.
Our Thursday evening family meeting is similar to iteration planning. The meeting starts with the prioritized to-do list. What are the most critical chores and activities?
Then the family estimates its capacity. Who and how much time is available to do the chores? A track or swim meet may consume most of one day, significantly reducing the capacity. Finally, it creates its planned list of chores and activities.
The Iteration
Agile teams collaborate to deliver small increments of value in each 2-week sprint. Every morning they huddle in a daily stand-up meeting to discuss what has been completed, align priorities for the upcoming day, and address issues.
For our family, the iteration is the 2-day weekend. The daily stand-up may occur at breakfast on Sunday, where they review what was accomplished on Saturday and readjust the priorities of what they will try to achieve that day.
Ending the Iteration
Two meetings occur at the end of each agile iteration, the demonstration, and the retrospective.
During the iteration, the team builds and tests small increments of work, and the product owner reviews and approves it. The demonstration allows the customers and stakeholders to review the work and provide feedback.
The retrospective is where the team embraces Kaizen—small, incremental improvements. The team meets and discusses what went well and what could be improved. Then, they identify specific changes that they will implement in the coming iterations.
The family may convene and inspect the freshly planted garden on Sunday evening. Changes to the garden and improvements to the process will be discussed. Adding more flowers will be discussed and put on the backlog for next weekend. Process issues such as replacing the old, broken shovel will also be addressed.
About the Author
Alan Zucker has over 25 years of experience leading projects and project management organizations in Fortune 100 companies. In 2016, Alan founded Project Management Essentials to share his passion for and experience in project management, leadership, and Agile.
Alan is a frequent keynote speaker and thought leader. He authors monthly articles, is regularly quoted in the industry press, and is a podcast guest. He is an adjunct faculty member at George Mason University and the University of Georgia; and is a senior instructor with several national, professional development organizations.
Alan has a master’s degree in economics from the University of Maryland and a master’s and a certificate in IT Project Management from the George Washington University. He is a Project Management Professional (PMP) and Certified Agile Professional (PMI-ACP) through the Project Management Institute. He also holds multiple Agile certifications from Disciplined Agile, Scrum Alliance, and Scaled Agile.
Visit Alan’s social media links to learn more.
Website: https://pmessentials.us
LinkedIn: https://www.linkedin.com/in/alanizucker/
Twitter: Alan @pmessentials_us
Browse IIL’s Agile and Scrum Courses here!
Our Annual Agile & Scrum Online Conference is available to stream now through September 4th! Register here.
Disclaimer: The ideas, views, and opinions expressed in this article are those of the author and do not necessarily reflect the views of International Institute for Learning or any entities they represent.
