Agile Estimation and Architecture Leads to Collaboration and Innovation


When team leaders develop and estimate multiple solutions, reviews of these solutions can lead to healthy discussion on priorities, business/IT collaboration on requirements, and product innovation.
 
Over several posts, I've described a disciplined agile practice that separates out Solutioning and Estimation from Story Writing and Sizing. Solutioning and Estimating is when team leaders will consider a prioritized feature, recognize multiple approaches and organize them into scenarios, break down each scenario into Story Stubs, consider architecture needs, and estimate them. Once a product owner selects a Scenario, the business analyst begins story writing on the prioritized requirements that are then Sized by the team.

At one of my team's recent feature review sessions, two solution scenarios with their estimates were reviewed. After some discussion, the team came to the conclusion that a hybrid solution might be optimal and then identified several additional capabilities for the business to consider. The team also reviewed what data they had and what they needed to make more informed, data driven decisions. These data gathering and analysis exercises were put on the backlog for research and will give additional insight on priorities and nonfunctional requirements. After the review with the Product Owner, the team began story writing and development on the essential requirements. The other identified capabilities were broken off as separate features for the Product Owner to consider and prioritize if they deliver sufficient business value.

It's this type of business and technology collaboration that disciplined agile teams practice and CIOs desire. 
continue reading "Agile Estimation and Architecture Leads to Collaboration and Innovation"

Five Key Agile Practices to Support Architects

Insuring Architecture needs fit into an Agile Development Practice.
Software Architects sometimes struggle with fitting in architecture needs within rapid agile development cycles. If the team is working on the product owner's top priorities, it is inevitable that there will be time pressures on completing and releasing them to users and customers quickly. This leaves little time for an architect to plan and develop architecturally sound solutions to business priorities.

There is a related question. When should architects and development teams target "good enough" solutions, ones that may introduce deliberate technical debt,  versus others where it is worth the investment to "develop right the first time" and produce reusable, scalable solutions.

A disciplined agile practice using some of the techniques described in this blog on estimating story stubs and sizing stories does help provide a framework to make these architecture trade offs explicit business decisions.

Agile Practice Fundamentals


First, the team needs to be performing light weight estimates off of the desired features. This provides a mechanism for technical leads to define solutions before all the requirements are developed. The Business Analyst or Product Owner should participate in this process to create assumptions that will become business rules if they align with business needs.

Second, the team must be disciplined in itemizing technical debt in the backlog. Without this discipline, any compromises on architecture will be forgotten and teams may have a harder time getting fixes prioritized.

Then, there needs to be a second process of story writing and sizing. When stories are detailed, there is a second opportunity for the leads and architects to solution and resolve architecture gaps.

Finally, there needs to be participation from the Product Owner. They need to be able to provide a high level feature road map that goes out at least several sprints out. The process of breaking features down, estimating, story writing and sizing can't happen easily in the sprint prior to development. Once a feature is prioritized, it needs to go through these planning steps which can have variable efforts and duration depending on complexity. Product owners can still shift priorities, but they have more information on cost/complexity as a feature is planned.

Fitting in Architecture Needs into a Disciplined Agile Practice


Architecture and other stewardship needs can easily fit into this process by taking on some additional governance and methods
  1. Governance - Does your product owner prioritize technical debt or architecture needs? Strong product owners realize the need to balance feature development and technology needs, but you may be working with product owner that doesn't show this discipline. It helps to define some governance such as defining a percent of velocity applied either per sprint or per release that need to dedicated to technical debt, stewardship, or architectural needs.

  2. Leverage the backlog - Architecture needs should be listed and prioritized in the backlog. This will force architects to sell their ideas or make business cases for them if these need to be developed and addressed.

  3. Estimate Multiple Scenarios - When features are estimated, consider estimating multiple solutions or development scenarios. In doing so, at least one scenario should represent the "good enough" solution, another that is architecturally "done right" and any number of hybrid or alternative scenarios. Leads and architects have to be judicious in selecting the number of scenarios because there is a cost to thinking through and estimating too many. Scenarios that are "good enough" should itemize potential technical debt and highlight risks/concerns while others that have better architecture should itemize potential benefits.

  4. Estimate Review Responsibility - Development organizations should decide who is on point for developing estimates and how scenarios and estimates will be reviewed.  The specifics on how this is done will be different for each organization depending on its size (how many teams working together), how roles are defined, and the size/complexity of the feature requested. It's important that the person or team reviewing challenge assumptions and make sure that complete solutions are not missing details or are over-engineered. In organizations that have architects, they should own this responsibility.

  5. Develop architectural values and principles - What I've described here is very systematic and process driven, but may not work all the time for smaller teams on aggressive time schedules. Teams need some basic guidelines, values, or principles that will help them make appropriate architecture decisions without a lot of overhead. These can't be hard rules and should be defined with some flexibility. But it should help architects make quick decisions on how to implement something, or how not to implement. Some of my principles including balancing value, innovation and research and simple agile product development
So where that leaves us is we have Governance to make sure that architecture and tech debt needs prioritized, a longer product roadmap so that technologists can think ahead, a responsibility to estimate multiple scenarios, a person or team responsible to review stories, and a set of guiding principles to help architects and teams make smart decisions and trade offs.

If you like this post, let me know and I will write a follow up.

continue reading "Five Key Agile Practices to Support Architects"

Measuring Costs in Agile Delivery

How much have you invested? *
One of the questions I sometimes get on Agile Delivery is on computing actual costs. My colleagues and associates know that I advocate a two step process - estimating performed by leads on story stubs and sizing performed by the team on fully written stories. I also recommend using points, not hours for the estimates and sizes because technologists can usually express more qualitative metrics like complexity rather than providing effort and duration related measures.

So How Do You Measure Actual Costs

Measuring actual costs turns out to be an easier process assuming that you have a tool to manage the backlog and a scrum master running daily standups. You'll also need to have some basic governance and insure that >X% of the team's activity is captured as stories. You don't want the team accounting for every hour at work as stories because there are administrative tasks, non-development work, special meetings and other activities that are not appropriate to account toward direct costs.

Approach

  1. You'll need to determine an hourly cost for the sprint. This can simply be done by
    • Know who will be on the team during the sprint and request the number of days that they will be absent during the sprint
    • Calculate, Hourly Cost for Sprint N = Sum(Hourly Rate * Number of Hours Planned Work in Sprint N) for each member of the team / (Total Hours Planned for Sprint N)
  1. You'll need to know how much effort was applied to each story which can be easily be done by the ScrumMaster during the daily standup. If Tim only worked on Story 1 yesterday and he worked 8 hours/day, then you know that this story consumed eight hours of activity. If Sara worked on two stories, yesterday, then I would suggest applying a 50/50 to each one unless she can provide more specifics. Use the agile backlog tool to keep a running total of Actual Hours per story.
  2. At the end of the sprint, calculate the total hours applied to all completed stories. Call this Total Hours Applied.
  3. The Cost for each story can then be calculated as Story Cost = (Hourly Cost for Sprint N) * (Actual Hours for the Story)
  4. If Features and or Epics are used to group Stories, their costs can be calculated by the sum of Story Costs for their associated stories.
  5. For Releases, you can also calculate the development costs by summing up the costs of the completed stories.

Exceptions

  • If Total Hours Applied varies significantly from Total Hours Planned, then that should be discussed during the retrospective. It implies the team put in overtime for the sprint, and would help for the team to reflect on the cause. 
  • In Step 3, I suggest teams only account for completed stories. I am suggesting the total costs of a Story be decided and allocated only on its completion.
  • A team can also choose to calculate costs associated with stories that are not completed or not released. 

Why Calculate Costs?

Once a story, feature, or release is completed the best metric to discuss costs with members of the Business (Product Management, Product Owner, Finance) are actual costs. Estimates and Sizes are good for team alignment and making smart decisions are made on what to prioritize and what to implement. But once prioritized and developed, costs are a better metric for comparing benefits versus actual investment.


* © Vilax | Dreamstime Stock Photos & Stock Free Images
continue reading "Measuring Costs in Agile Delivery"
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.