Defining the Agile Planning Sprint - Feature Estimation

In previous posts, I've written about Why and How to Estimate in Agile, How to Conduct a Story Sizing Meeting, and on Five Key Agile Practices to Support Architects.

In this post, I'm going to get a little bit more detailed in what I call an Agile Planning Sprint. This post will cover the process on providing Agile Estimates. In other other posts, I will describe other tasks/deliverables of Agile Planning.

The purpose of Estimation as part of the Agile Planning Sprint is simple - take newly defined features, solution them into scenarios, break scenarios down to story stubs, and estimate the stories. The purpose of this cycle is to give the business stakeholders a first estimate of costs and tradeoffs on what to include or not include in the feature's scope. It also gives technical leads a quick process to develop solutions and consider the complexity points.

Here is a one week sprint that can be leveraged to estimate features:
  • Day 1, Business Stakeholder Session - At a meeting of stakeholders (including product owners, and senior technologists), three agendas are scheduled:
    • Feature Backlog Review - The Program Manager reviews status on the top features in the agile planning backlog and reviews status.
    • Solution Review - All Features that were estimated over the last agile planning sprint are reviewed with stakeholders. These are given "go/no-go" votes and "in/out of scope" on specific feature details. Features given a "Go" will go into the next task in Agile Planning - Requirements Gathering and Story Writing - which will be covered in another posts.
    • New Feature Prioritization - The sponsor of a new feature presents the feature definition and its business value. At the end of this meeting, new features are voted on and the feature backlog is prioritized with the new features.

  • Day 2, Agile Planning Session - The technology / program management team reviews the feature backlog for new features and progress on old features. Team leaders (often tech leads, business analysts, and QA leads - but that depends on your organization) commit to features estimation.

  • Day 3-4 - Team leaders work on tasks. For features in agile planning, Team Leaders develop multiple scenarios (options) to fulfill the requirements. At least one scenario should represent a "minimal feature set".

  • Day 5 - Architectural Review Session - Team leaders present their story stubs, estimates, and assumptions to architectural and program leads. For each feature, the architecture team makes the following decisions:
    • Ready for Solution Review - Architects review the feature and decide the stubs and estimates developed by the Team Leaders fully represent the requirements and technical dependencies of the feature. The team decides which of the Scenarios should be presented at the Feature Review, and which can be left behind. This team also considers what feature elements should be reviewed for "in/out of scope".
    • Additional Estimation Required - The architect team can force a feature in for a second round of planning if the story stubs don't represent an end to end feature definition, if the estimates are challenged and need review in more detail, if dependencies on other teams need to be considered, or if additional scenarios need to be developed.
In this process I'm stretching the definition of "sprint" and deliberately selecting a fast one-week cadence. The stretch is because a feature's planning might not achieve 'done' (as in estimation complete) at the end of a week either because its complexity requires more planning, or because it does not pass the architecture review. This is by design; complex features that require multiple planning sprints become feedback to the stakeholder - maybe you're feature is too complex. It also forces quick estimates and solutions since many features will not make it to the next task in Agile Planning - requirements gathering and story writing.

continue reading "Defining the Agile Planning Sprint - Feature Estimation"

5 Ways to Improve Agile Team Velocity

Relay Race Team practice to improve performance
An agile team's velocity is based on how the team sizes stories and how many stories and story points they commit to each sprint. Agile's self organizing principals empower teams to make these decisions in exchange for their commitment to complete the stories and having "shippable code" at the end of every sprint.

But what happens when management needs the team to accelerate its delivery? What happens if there is a significant opportunity or critical deadline and management wants the team to take on more stories or story points in a sprint?

Here are a number of ways management can either help, or influence its teams when this is needed:

  • Leverage Retrospectives - Retrospectives are part of most agile practices and give teams time to reflect on what worked well and what can be improved in the development practices or processes. I'd recommend management ask the team to consider a higher velocity as a discussion point during the retrospective. I'd also make it clear that the team should recommend steps that is under their control so that the exercise doesn't dissolve to a list of out-of-team improvements.

  • Increase Planning - I tell teams that they should target to have a backlog of two sprints of full defined stories, and an additional four sprints of story stubs estimated. If the product owner feels strong about the prioritization and definition of the backlog, it may help teams to dedicate blocks of time to get ahead of planning and target as much as four sprints of defined stories and an additional eight estimated. The added visibility gives teams the "big picture", helps them see dependencies, and gives them more time to find easier solutions.

  • Analyze Causes of Rework - All agile practices have a certain amount of rework in the form of changed requirements, poorly defined requirements, technical debt, defects, performance considerations and other sources. Teams should consider labeling stories (or tasks) based on the source of the rework, then consider measures that might reduce this work.

  • Learn the Customer - The Product Owner has got the tough job of aggregating many inputs from different user segments, sales teams, customer care feedback, research, and usage data. Development teams can play a role by insuring Product Owners have better data and more technical insight to make smarter decisions on what capabilities (stories) are required and what priority to fulfill the customer need. It can also lead to better technical design. So for example, if a feature is required by top customers but is not heavily used, perhaps the performance criteria can be relaxed and lead to an easier to implement design. 

  • Implement Smarter Solutions - Are teams leveraging existing code? Should a capability be developed as a service because it will have short term reuse, or should other capabilities take on deliberate technical debt? Are features too big, and will breaking them down, labeling them, and discussing with the Product Owner lead to lowering the priority on some of them? Are estimates challenged to help find better, more efficient solutions? In my experience, these disciplines can be overlooked by teams yet they can lead to better more efficient solutions.

You might argue that some of these steps don't directly improve velocity but are in fact measures to consider multiple solutions or reduce scope. This is technically true, so if you take on some of these approaches you might not see a direct percent increase in team velocity, but you might see the team deliver more capabilities in the same time frame.


continue reading "5 Ways to Improve Agile Team Velocity"

CIO Advice for Taking Summer Vacations

Lounge Chairs Under A Palm Tree Summer time. Lemonade. Swimming at the beach. Nature hikes. Sailing. Summer movies. Gourmet picnics. Outdoor music. Margaritas. Hammocks. Gardening. Barbecues. Novels. Biking. Fishing. Festivals. Peaches.

But can you break away from the email? Delegate attendance on a key conference call? Complete your key tasks before jumping in the plane or car? Read something non-technical?

Can you turn off your mind from solving problems?

These are the things I think about in the days heading into summer vacations. Can I get a clean break, avoid the temptations to get pulled back into the grind, and use the time for both relaxation and enrichment?

I have to admit, it's hard and I'm rarely 100% successful. You plan your vacation months before, so who's to say that you can truly pull out from whatever priorities, crises, or other scheduling conflicts.

So the best to I can, here are some tips:

  • Bury the email - Leave the iphone in the car or hotel. Hide the email app so it's hard to reach. Let's face it, we're going to bring these devices but we don't have to let them advertise what you're missing at the office. I look, but try to read email early in the morning or later at night.

  • Stack the Kindle - I'm optimistic that I will get to read books on vacation and I'm not talking about the top management, technical, or financial books. So I'll stack my Kindle app with novels, travel, and other books that pull me in new directions. I like to jump from book to book and rarely make it end to end on a single book one at a time, so before the trip I will do my research and have several selected.

  • Set Priorities - Make sure your team has clear marching orders for when you are away and let them know what you want to review when you return. Set "read out" sessions in advance. Hopefully, this will give you a sense that things are moving along in your absence and help you avoid getting into the weeds while away.

  • Teach something / learn something - In order to fill the problem solving void, pick one or more learning topics. This may be something new to teach your kids, something out of left field for you to read and learn about, or an activity that will immerse you in something new to experience.

  • If needed, establish a Bat Phone - If you are truly concerned how someone should reach you in the face of a real, unexpected crisis, give a trusted lieutenant or your assistant a non-email, best way to reach you.

  • Build Memoirs - I photo and blog my vacations. You may have another family member doing this already, but I highly suggest taking on an active role. Sorting and tagging photos, or documenting your travel story - in addition to building memories for the future - is another way to feed your technical urges to download or tinker with apps.

Happy Summer


continue reading "CIO Advice for Taking Summer Vacations"
Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.