Agile Expectations Board

An Agile Expectations Board seeks to prevent an Agile project from successfully delivering Iterations on the way to abject failure. It focuses attentions on the deficiencies early on, thus making sure they are addressed. An Agile Expectations Board can be used in addition to existing tools and methods - you can use it in a Scrum project, or hang next to a Kanban board. It can also be used for an unbranded Agile project that utilises some Agile techniques - like User Stories, rapid iterations - in a way they choose.

The Agile Expectations Board was inspired by the Agile without Magic Manifesto. An Agile Expectations Board however assumes that the project runs rapid iterations. It cannot be used for a Waterfall project.

What is an Agile Expectation?

Agile Expectations are generic conditions the project should satisfy, selected according to the following criteria:

1. Represented and biased. Each promise must be represented by a Stakeholder who is capable of assessing whether the condition is satisfied. A Expectations requires Stakeholder satisfaction with a particular facet of the solution, however should not attempt to define objective success criteria.
2. Generic and limited in numbers. A project is expected to have a handful of Expectations.

Agile Expectations Template

And Agile Expectations follows the “X is expecting us to Y”, where X is an individual stakeholder

Expectations are not Requirements

Expectations are not specific nor detailed to be seen as Requirements. More likely, an Expectation is a very approximately defined promises to address Requirements of a particular Stakeholder, without specifying them.

Furthermore, an Expectation can pivot through the course of a project. A Stakeholder can become convinced that their Expectation is not worth the effort, or something much better can be achieved easier.

User Stories are not Expectations

There are different interpretations of User Stories. Traditionally, a User Story is defined as a “promise of communication” which is effectively a conversation starter, that can result with the team doing something quite different. However some sites treat User Stories as signed-off Requirements that should be addressed without further need for communication with the Stakeholders and Subject Matter Experts, and definitely cannot be modified or re-interpreted.

It is a good idea to define the role of User Stories as an expectation. Say “Doman Experts expect us to implement User Stories in whatever order we choose” or “Domain Experts expect us to address each User Story in order of importance, and clarify the meaning and implementation through joint development” etc.

In any case, it is on Expectation for all User Stories in the project.

Design of an Agile Expectations Board

General Layout

You can draw a Board with Iterations going from left to right, or with Iterations go from top to bottom. The following examples assume the former layout.

You start a Board by writing the main statement:b

“I observed the project proceeding toward meeting my expectations, in the way that I could understand, and relevant to my role”

Layers of Abstraction

Business Abstraction defines four “Levels of Abstraction”, which are defined in terms of the audience that can understand information in a particular Layer:

1. Strategic Layer contains information for senior executives. It is free from technical details, but also from specific business details. It is the information your CEO or Department Secretary has time for.
2. Business Layer is strictly computation-independent, however can go into details. For example, Business Layer for the Medici Bank in 1397 would be surprisingly similar to a late 20th Century retail bank. Business Layer can be split vertically into the Enterprise Business Layer, that talks about how the business works, and the Customer Layer that looks at the Customer needs and circumstances in the relation the the business in hand. The audience for Business Layer are Business executives and Domain Experts involved in day to day running of the enterprise, Business Process Analysts, User Analysts. They are happy to get into details, and review individual cases, however would not necessarily know how to operate specific software system.
3. Functional Layer deals with behavior of software systems, without looking into how the system is built. It is the domain of traditional Business Analysts, and usually of the less technical Architects.
4. Technical Layer is the domain of Software Engineers, Database Administrators, and other technical staff.

You need to draw 4 Levels. Give more space to the Layers you expect to be busy, and little to the Layers you don’t expect have much Expectations.

Writing Expectations

Each Expectations should be represented by a Stakeholder, not necessarily exclusively, however no more than a couple of Expectations per stakeholder.

The next step is to write Stakeholders, and their Expectations. Follow the following rules

1. When you meet a Strategic Expectation, it would possibly make it way to the next Annual Report.
2. Anything that mentions specific applications belongs to the Functional Layer, or the Technical Layer below it.
3. Anything that mentions code or tools belongs to the Technical Level. Do you have Expectations of that level of details? They can only come from a hands-on Stakeholder, or a Stakeholder that has hands-on advisors.
4. Business Layer deals with individual Customers, Requests etc - too detailed for Strategic, yet Computation-Independent

Always make sure that there is some space within the Layer below the expectations, as sometimes you need to add Expectations mid-project.

Your Board is ready for your first Iteration.

Recording an Iteration

At the end of an Iteration, you need to draw a vertical line, write a date or Iteration number, and then see which Expectains were reaffirmed. For each Expectation, send a text to the Stakeholder[s], asking whether they can say that it describes what they observed, whether they see it as an affirmation of the project proceeding toward meeting the particular Expectation, in the way that they could understand, and relevant to their role.

If you have their support, you can write the description in the relevant cell. However for each Expectation for which you have nothing to write, you need to fill the cell red

You can consider reviewing expectations of a Strategic-Level Stakeholder every second Iteration. However if you have nothing to write for the second Iteration on the row, you need to colour both cells red.

The rules for identifying a correct Layer

Follow the similar Rules as for recording Expectations:

1. Anything that mentions code, a programming language or a software tool belongs to the Technical Layer. The same goes for Unit Testing outcomes.
2. Anything that mentions specific Applications belongs to the Functional Layer. The same is true about User Stories, which do describe working with one or more Applications.
3. Anything that mentions algorithms by name, belongs to either Functional or Technical Layer, depending on how well your Functional Layer understand Analytics.
4. To get on the Business Layer, you have to address policies and laws rather than User Stories
5. Business Layer also deals with individual Customers, Requests etc - too detailed for Strategic, yet Computation-Independent
6. Things you bring to Strategic Layer are usually either measurable, or related to compliance.

Pivoting an Expectation

When an Expectation is no longer valid, either because the Stakeholder changed their mind, or was ruled out no longer having a say over project, write an explanation and cross out the next cell

If the Stakeholder changed the Expectation, write the new one, and draw an arrow to the next Iteration

Why Draw Expectation Board?

Expectations Board for the Primary Stakeholder

The Expectations Board was created to avoid situations like the one below. It is a hypothetical situation, however it is based on real-life examples, and by no means an exaggeration.

So you have a project that should bring the wonders of AI to, say, an insurance company. The team has bright people with great resumes, they run Scrum, they hold stand-up or even in-plank meetings, they report successful completions of their Sprints.

However, let’s look at the Board below:

For the first Iteration, the report was referring to tools (Apache Spark), so it was bumped to the Technical Layer. The second iteration was about running some algorithms, which delegated it to the Functional Layer. The third can be seen as Functional or Technical, but definitely not above. And when they delivered some demonstration at the Iteration 4, it had nothing to do with business data, so also has to be delegated Functional.

As a result, the project that did all the Agile rituals ended up with two thick red bars that have to attract attention.

Of course it can be argued that a competent Scrum Master would detect something wrong with the Iterations right away. However, every project believes they have right skills on board, but not every project has. The Board visualises the problems, making them much easier to spot.

Expectations Board for the Secondary Stakeholders

Perhaps the main contribution an Expectations Board can deliver in relation to the secondary Stakeholders.

Most Agile methods were either originally developed for Internet companies, or hail from the times when Application Integration and Enterprise Architecture were not as prevalent - so they had to focus on the primary Stakeholder only. However, any solution development in a large enterprise have a lot of secondary Stakeholders, people who have to ensure the solution continue to works for the enterprise long-term. Solution Architects must ensure the solution can be kept safe from intrusion, Enterprise Architects want to make sure the solution would stay relevant within the broader context, Business Systems Operations Manager wants to make sure they would be able to support and modify it as needed.

Such Expectations, addressed through the Development stage, would ensure the system would considered a success not only one the day it is delivered, but for years to come.

Expectations Board and Cross-disciplinary Teams

Cross-disciplinary teams try to address similar concerns by bringing Developers, Business Analysts, Application Integration, Operations etc specialists into the same team.

It is a highly beneficial development, however a Team Member is not a Stakeholder. A multi-disciplinary team would not replace an Expectation Board, yet would make addressing the Board much easier.

Originally published at https://www.businessabstraction.com/data-enterprise/agile-expectations-board/

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.