The language they understand is months and dollars (or any other type of currency).

The language they understand is months and dollars (or any other type of currency).

Clients, stakeholders and pointy haired bosses really do care about how long a project will take, how much the project will cost and by extension the effort required to deliver the project. What clients, stakeholders and bosses don’t care about is how much the team needs to think or the complexity of the stories or features, except as those attributes effect the duration, cost and effort.  The language they understand is months and dollars (or any other type of currency). Teams however, need to speak in terms of complexity and code (programming languages). Story points are an attempt to create a common understanding.

When a team uses story points, t-shirt or other relative sizing techniques, they hash a myriad of factors together.  When a team decomposes problem they have to assess complexity, capability and capacity in order to determine how long a story, feature or task will take (and therefor cost).  The number of moving parts in this mental algebra makes the outcome variable.  That variability generates debates on how rational it is to estimate at this level that we will not tackle in this essay.  When the team translates their individual perceptions (that include complexity, capacity and capability) into story points or other relative sizing techniques, they are attempting to share an understanding with stakeholders of how long and at what price (with a pinch of variability).  For example, if a team using t-shirt sizing and two week sprints indicate they can deliver 1 large story and 2 two medium or 1 medium and 5 small stories based on past performance, it would be fairly easy to determine when the items on the backlog will be delivered and a fair approximation on the number of sprints (aka effort, which equates to cost).

Clients, stakeholders and bosses are not interested in the t-shirt sizes or the number of story points, but they do care about whether a feature will take a long time to build or cost a lot. The process of sizing helps technical teams translate how hard a story or a project is into words that clients, stakeholders and bosses can understand intimately.

Business and Technical Stakeholders Must Both Be Involved In Demonstrations

Business and Technical Stakeholders Must Both Be Involved In Demonstrations

In order to efficiently gather feedback and support, demos require broad involvement. Involvement must include the team and a cross section of relevant stakeholders. Stakeholders should span the interests of both the business and technical environments.

Business stakeholders include those representing product and back-office functionality. The stakeholders bring the understanding of market needs and wishes for both customer facing products as well as applications used within the organization to the sprint team and to other stakeholders.

Technical stakeholders include data and technical architects, process improvement personnel and DevOps teams that might need to provide guidance or direction to the sprint team. The technical feedback helps the team to stay within the environmental constraints of the organization.

The demonstrations bring the business and technical stakeholders together with the sprint team to generate feedback. The different perspectives that the business and technical stakeholders bring to the table extend the knowledge of the team. Teams that constrain participation in the demo rob themselves of significant input that may have to be “discovered” later in the project, which can generate customer dissatisfaction and rework.

Demonstrations are not presentations.

Demonstrations are not presentations.

Demonstrations, also known as demos, are Agile’s mechanism to share what the team has been accomplished during the current sprint. At root, the demo is a show and tell that provides the team with a platform to describe what has been accomplished. Demos build confidence and customer satisfaction.

Demonstrations occur on the last day of every sprint. They show the stakeholders what has been accomplished during the current sprint. The goal is for the team to gather feedback from the stakeholders so that they build what is needed and what the team committed to at the beginning of the iteration. The transparency created when the team shares its performance allows the team to rush toward feedback, while selling progress. Good demos include stakeholders interacting with the software so that everyone understands exactly what has been developed.

Demonstrations are the teams mechanism to gather feedback and to ensure they are delivering value. I believe that demos have two currencies. The first is working software and the second is feedback. Teams build cache when they say what they are going to do, do what they say and listen to how their stakeholders feel about what they deliver.

Release Planning requires many voices.

Release Planning requires many voices.

Agile release plans communicate what and when the project is going to be delivered. The plan is a dynamic tool that reflects the business and technical environments. In order to create a release plan, the team and a range of stakeholders representing technology and business leadership need to be involved.

The typical Agile team is comprised of a scrum master or coach, a product owner and a development team. The development team includes all of the capabilities needed to deliver the work that is taken on by the team. Capabilities include skills of developing, testing, business analysis, architecture, design…and the list can go on forever. The point of view of the Agile team is constrained by the knowledge that they have to develop and deliver what they are being asked.

Business stakeholders bring the knowledge of the market and the organizations goals. They can and typically do include people from marketing, sales, manufacturing and customer service. The list of business stakeholders can be quite long, and most projects rely on the project sponsor to help constrain the list. Each stakeholder brings the point of view of his or her constituency to release planning.

Technology stakeholders bring knowledge of the organization’s technological goals to planning how the project will release. Technology stakeholders include those that speak for software and technological architectures (current and aspirational) and IT’s strategies for the balance between building and buying, networked or un-networked computing and in-sourced or out-sourced staffing. Strategies and architecture can influence what functionality will be delivered and when it can be delivered.

Each group of stakeholders represents a constituency that has needs that the functional and non-functional requirements that an IT project will attempt to deliver.  All of these needs must compete within the constraints of what can be done. The release plan reflects the current prioritization of the project’s needs based on the constraints and goals of the organization as represented by the projects stakeholders.