Agile Testing Practice: First Basic Steps

Agile testing is such a huge topic. Probably we could only scratch the surface in this post. But, what I would like is to talk about some really basic concepts and practices, without which we would not even be able to pick the low-hanging fruits from the tree of Agile Product Development. So, let’s start the journey!

As you know, in Agile/Scrum, value is delivered to customers through the completion of Product Backlog Items (PBIs). A PBI could be :

  • a users story, which brings direct and immediate business value to customers,
  • or a description of one or more bugs, which resolution will help customers to gain business value,
  • or a technical story (e.g. refactoring some source code to improve performance, install a new Continuous Integration server, have some architectural development to sustain new business features, etc.), which brings business value indirectly to customers,
  • or a spike (technical or analysis feasibility, take a look here to one of my previous posts), which value is in gaining the necessary knowledge for the team to be able to satisfy a user need,
  • or any documentation needed (user manuals, technical diagrams, etc.)
  • or any other kind of work or activity which is worth doing for the product!

Any PBI must pass through the Plan, Design, Build and Test phases, before being presented to the Product Owner for the acceptance.

Well, one of the most challenging phases is actually Testing.

Agile Testing

According to the last letter (T > Testable) of the INVEST acronim, a story must be testable and in order to do that, we must pass through some specific steps.

First of all, the product owner gives clear and enough information on what the system should do to deliver specific value, describing it through a user story like this example:

As a user of the home banking portal, I want to print the receipt of a money transfer operation I submitted, so that I can review its correctness and store on my private area in the portal

Then, the whole Scrum team reasons on how the story will be tested and demoed, specificing relevant acceptance criteria (see my previous post here). Usually this is ultimately done in the first part of the sprint planning meeting.

Moving forward, it’s time for the development team, during the second part of the sprint planning meeting, to reason about the “how”:

a first high level design of each committed PBI is done, which ends with technical tasks decomposition.

Oh, c’mon Emi….so far no news at all !!! Ok, ok, let’s push a bit on the accelerator then.

Testing Tasks on your Kanban Board

Regarding the testing activities, the teams should have been created, for each user story, something similar to these tasks: Test Scenario & Cases Design, Test Scenario & Cases Development, Test Cases Execution, Test Cases Automation, Final Validation.

Test Scenario & Cases Design

Firstly, let’s get rid off any misuderstanding about Test Scenario vs Test Cases: a Test Scenario is WHAT behavior we want to test; a Test Case specifiy HOW we are gonna test it (input data, output expected, variables, steps, etc.).

Well, this first design phase is key to the success of the whole story.

The team member/s who will develop the story (let’s call her developer) and the team member/s who will test it (let’s call him tester) meet and discuss how the story will be implemented (UI, any business rules, happy and alternate paths, data, performance, etc.).

This helps the tester to start clarifying all the possibile (known) business workflows a user could walk along and, on top of them, make a first risk analysis to discover what are the paths more subject to errors and crossing them with any business critical points (e.g. money transfer submission, credit card data confirmation, etc.).

The results of this is the identification of test scenarios (and most critical ones) and related cases, assuring an end-to-end functional testing. In this phase is of great help if also the end-user could join the discussion, actually largerly increasing the effectiveness of the final results.

Test Scenario & Cases Development

At this point developer and tester come back to their workstations. The former start developing the application and the latter writing the test cases, according to the design above mentioned.

This testing activity could be significantly time-consuming because pre-conditions, data, conditions, expected outcomes and the like, are finally transformed into detailed steps of the test cases. In case of any doubt, both the tester and developer could meet and clarify and finally review them together.

Two important aspects must be taken into account.

The first regards the fact that product functionalities and feautures are bult incrementally and same is actually for test artifacts: they grow incrementally, therefore maintainability is paramount and must be thought accordingly.

The second is traceability.

Traceability between features, PBIs, test scenarios and test cases, must be assured according, again, to the incremental approach mentioned. Additionally, every eventual new bug that pops up, shall be addressed and the related test case must be clearly identified and fixed.

Test Cases Execution

When the developer finishes her development tasks and move each and every related tasks in the Done column of the Kanban board, if the tester has already finished with test cases creation, it’s time to execute those cases against the new functionality.

Each step of every test cases belonging to that scenario, is then executed following the workflows previously written. Any bugs must be notified to the developer, which should fix them on-the-fly (if possible); otherwise it will be tracked into the defect management system.

Test Cases Automation

Well, when every story is finally successfully tested, it’s time to test automate it. Why?!

Because of the incremental product development approch of course! Starting from the first iteration the team develops some stories, then in the following sprints they build other stories on previous ones and so forth incrementally (like with a construction with LEGO blocks).

If the team does not automate tests, it happens that regression testing will become more and more complicated and, moreover, too much time consuming: while time passess, number of stories developed increase and manual testing everything is impossible. This has two different potential side-effects:

  1. The team in order to deliver the functionalities promised, decreases the attention and related effort towards testing (poor quality).
  2. The team remains fully disciplined and committed to quality/testing, deliverying less functionalities (poor performance).

Now, both must be avoided. It is very important for team members to find a good compromise on how much effort they should spend in testing automation. This can be done only distinguishing between the different types of automation testing and the relative effort that it is reasonable to spend on it (the design phase above is key here).

Some examples of testing automation practices are Unit Testing, API or Service or Behind the GUI automation testing and UI automation testing. Everyone has its own specificity that desevers more space and time to be covered. I’ll leave this for future posts.

Final Validation

The last task a tester should execute before putting the entire story in the so called “TO ACCEPT” column for the Product Owner, is the final validation, where some explorative, edge testing activities or, if requested, some performance or load testing happen.

Well done!

Now, please, turn around. Look at your kanban board. How many testing tasks do you have on it? What?

Just a single, poor and generic task called “Testing”?

Cheers 🙂

Agile Teams, Measures and KPIs

When you dig into this topic, you find tons of discussions and debates about what metrics and KPIs to use when “running” Agile and if they are helpful or misleading. This post wants to explain when and what KPIs can be used, to lead your team towards relentless improvement.

As a Scrum Master, Coach, Agile Leader, your work is to facilitate your team to grow and improve with a constant pace, sprint after sprint. In doing that, you must be as much as possible objective in measuring improvement; that’s key to drive decision making and to identify actions which lead to increase effectiveness of your team.

One of the most famous quotes of Peter Drucker says:

If you can’t measure it, you can’t improve it.

Drucker meant that unless success is defined and tracked, you never know if you reached it or not. His suggestion was to clearly establish metrics for success, then track progress and, according to that, adjust your process to produce the desired outcome. Without clear [SMART] objectives, you’re stuck in a constant state of guessing.

Another interesting quote from the American professor and statistician W. Edwards Deming says:

“In God we trust, all others must bring data.”

Yes, it definitely makes sense, too.

Actually you should know that, despite any healthy approach and endeavor in helping your teams to improve through any measures and KPIs, better results may be long in coming.

Why?! Reasons may be different:

  • Fear: of changing, of making mistakes, of being judged.
  • Team Dynamics: lacking of trust between team members or unaddressed conflicts.
  • Transparency: unclarity about project’s vision and mission or team’s roles and responsibilities,
  • Burnout: too much stress or overload.

Furthermore, we need to keep very well carved in our mind, that KPIs and measures are just proxies of the reality. Not the reality.


Said that, KPIs could help. Let’s see a short list of them, which agile teams could use to track their progress towards improvement.

Monitoring the Scope

First of all, having a graphic view of the status of the scope in terms what has been done and not done, helps a lot.

Additionally, a high level view of which part of the scope belongs to which release, is another important information. Every information contained in the product backlog is a living element, which is updated according to refinement activities as well as release planning events (which are highly recommended for complex projects).

Once your team planned for a release (usual duration from 8 to 12 weeks), you should be able to draw a Release Burndown Chart, like the following one, where the total scope for the release is reported on the Y axis against time (X Axis) and updated with actual data. This helps to see any deviation from the trend line.

In order to make forecasts for the whole product development or project duration, the tool we can use is the BurnUp Chart. This chart shows:

  1. A (blue) line, which represents the total scope in story points, tracked at each sprint boundary
  2. Histograms (green) that reports the cumulative scope burnt in story points (sum of story points accepted, velocity), for each sprint
  3. A (red) trend line, which projects future performance (velocity) according to past performance

The intersection between the red line (trend) and the blue one (total current scope) gives the future sprint number, when the team completes the whole scope.

When teams want to verify the scope they work on each iteration and investigate on its nature, they could track and plot how many story points are:

  • loaded into the sprint (Committed),
  • added by the team in case of any discovery activites during the sprint,
  • requested by the team when finished to work on the planned user stories,
  • Added by PO (TO AVOID)

Every category (added by PO excluded) is allowed and can be considered a usual behavior. Any recurring pattern, however, is a sign that could be investigated.

Monitoring Performance

The most utilized KPI here is the Velocity, which is the sum of the story points finished by a team (according to the Definition of Done) and definitely accepted by the Product Owner (PO), within an iteration (or sprint).

Scrum is strongly geared on the PDCA cycle from Deming. This cycle strongly stresses not only the importance of planning (P) and doing (D) activities and actions, but it helps to focus also (and foremost) on investigating (check – C) results and adapting (A) your plans/behaviors to improve.

This important concept of gathering and analyzing feedback about past iterations, is one of the pillars of the Agile Manifesto (12th Principles):

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Scrum implements it through the Retrospective Event. Any actions which aim to improvement of produtivity, reducing of cycle time, throughput increasing, should be positively reflected by calculating the ratio between previous and current sprints velocity. The result is a percentage that can be plotted as follows.

Tracking Waste

Lean teaches us that waste must be always avoided.

In Scrum everything is built around that concept: batch dimensions (user stories and tasks) are kept small thanks to strict timeboxes (sprint, scrum events duration, etc.), Focus and Commitment are behaviors continuosly remarked and reminded (being also Scrum Values). The two roles of Scrum Master and Product Owner, help in shielding the team and clarifying responsibilities within the team. Colocation enhance communication and decrease misunderstanding, etc.

An important dynamic we would like to monitor, is that every effort spent by the team, delivers actual value for the business. What is expected, hence, is that every story finished by the team, is subsequently accepted by the Product Owner.

Exceptions are obviously more than welcome, but any recurring pattern must be investigated because it could hide communication problems between PO and team, difficulties with Acceptance Criteria, problems with the Definition of Done. The graph below helps in finding gaps between finished and accepted story point values.

It’s possibile to generalize and represent that phenomena as absolute figures. The Focus Factor is the calculated ratio between [Finished Story Points] and [Accepted Story Points]. We can then plot those numbers for every sprint as follows:

Quality Measurement

Creating bug-free products is something we should aim to, but that is not always possibile. This means that keeping track of bugs is a mandatory practice to measure quality. We would like to measure how many new bugs have been discovered during the past iteraction, how many have beed closed and how many are still remaining.

Other important measures we could track are # of Test cases and percentage of automated ones, code coverage % for unit tests, technical debt measurement through static source code analysis (see my previous post “Relentlessy avoid technical debt“).

People Engagement and Satisfaction

Last but not least, we want to measure satisfaction, motivation and engagement of people involved in Agile development.

Measuring team members’ mood is a good habit and it could be done through temperature reading just before finishing the retrospective, or by “reading” the satisfaction through Niko-niko every day.

This data can be collected and shown as KPIs over time as information radiators.


Finally, I like to end this post citing John Hayes:

“We tend to overvalue the things we can measure and undervalue the things we cannot.”

Thus, don’t forget we are humans largerly influenced by emotions; additionally, we, as Agilists, want to enable energy and interactions between individuals, and only then, rely on processes, tools and even on Measures and KPIs.

Safe travels :o)

[2nd Part] Why (What? How?) you should Embrace Agile and Lean, to Manage your Portfolio

In my previous post I explained some of the foundemantals steps for implementing an Agile and Lean Portfolio Management. Want to know how actually strategy drives execution of company Big Initiatives, through Agile and Lean?!

In my previous post I wrote why Agile/Lean Values and Principles are the most critical point to start with, also for Portfolio Management; then I proceeded explaining what are Values Streams and how they drive the whole portfolio development. Going further, I wrote about prioritization through Cost of Delay (COD) and Weighted Shortest Job First (WSJF) and finally proposed a possibile process for portfolio management and the related kanban board.

In this post I would like to explore how strategy is bridged with execution, and how Lean and Agile together create the most effective approach to avoid waste, remain adaptive and deliver value rapidly.

Bridging Strategy with Execution

Strategic Themes

Fine. The journey starts when top management decides what will be the company strategy for the next year/s (1? 3? 5?). Usually this phase produces a list of Strategic Themes the company should pursue. Every strategic theme has at least a title, a description and obviously expected benefits.

Examples of Strategic themes’ titles a compay could have: Attract younger people (e.g. Millennials), Digitalize 80% of Company Internal Processes, Redesign the user experience for retail customers, etc.

Then, a first budget allocation is made, dedicating slices of overall budget, for each strategic theme.

Big Initiatives & Value Streams

Well, now it’s time to identify the list of Big Initiatives that realize the expected value for each Strategic Theme: One Strategic Theme -> Many Big Initiatives.

Then, for each Big Initiative, a high level “analysis” (Agile Feasibility, not Big Analysis Up Fornt!) is executed, which explores the vision, benefits, raw cost estimation (teams involved, necessary resources), etc, of the initiative itself.

This step is represented in the Portfolio kanban board by the column Analysis (previous post here).

Usually I conduct that high level Analysis or Agile Feasibility, by using the DAD Inception Phase. I wrote about this in one of my previous post here: “Getting a big and complex project off, from the starting blocks with Agile (DAD Inception)“.

Then, people and teams involved, sequence of actions, usage of resources, knwoledge and expertise, represent, all together, the Value Stream through which pursue and deliver expected value: from concept (trigger) to cash (value).

Now it’s time to fund the initiatives. A budget is allocated (and dedicated) for each Value Stream. The picture below puts everything together.

One important piece of news, is that the Agile iterative and Inspect/Adapt approaches are also used for Budget Allocation. Actually budgets, for strategic themes and value streams, are initially allocated as usual, but they are revised at least every quarter. What does it mean?

It means for example that the overall budget allocated for a specific Strategic Theme, is decomposed in slices and assigned to belonging value streams. Then, according to effective progress and results of each value stream, and eventual market change, every quarter budgets could be revised and re-balanced beteween the value streams belonging to that strategic theme. The Portfolio Management team is responsible to autonomously rearrange budget at quarter boundaries,

Flavors of Lean in Portfolio Management

Lean is key to Portfolio Management.

It helps to reduce waste, decrease time-to-market, and drastically improve quality thanks to Pull System and concepts like JIT and WIP Limiting.

A Pull System provides that development or production should be ‘pulled through’ rather than ‘pushed through’ the productive system

Systems like those, are literally driven by customer requests and thus worked just in time, as productive capacity is available. This assures that the companies adopting these systems, to produce what is strictly necessary and actually requested by the market/customers,

Another foundamental gear of a pull system is Just-In-Time (JIT) concept.

In lean manufacturing JIT means producing and delivering finished goods ‘just in time’ , right before being sold, just enough to meet current demand.

It means for Portfolio Management that a new phase of the process won’t start before the previous one is triggered and finished and, furthermore, that work will happen according to available capacity and customer demand.

A final important concept necessary to implement an effective pull system, is WIP Limit. WIP is an acronym which stands for “work in progress”.

Limiting WIP is a strategy for preventing bottlenecks, avoid over-production, avoid waiting times and it generally improves flow by creating a steady pace between the production phases.

Let’s see now how the concepts above mentioned, are applied to Portfolio Management. As mentioned in my previous post, a usual portfolio process and relative kanban board is like this one:

New initiatives or ideas arrive in the Funnel. I usually use this lean canvas which summarizes basic information that finally represents the card in the kanban board:

The subsequent phase Review, is meant to review, refine a bit and validate the basic information, figures and facts of each item in the funnel, assigning a first piority. New relevant information are reported also in the card, stressing another lean concept (Visual Management), in order to facilitate visualization and immediate understanding.

Then, when an initiative is pulled through the Analysis columns, the Agile Feasibily is executed, in order to envisage high level scope, architecture, risks, benefits and costs.

In order to avoid too much analysis, as mentioned in my previous post, this phase is also executed in an Agile manner (using Scrum), collaboratively and doing not much Analysis. The final outcome is a Lightweight Business Case which reports the main assumptions and results. I use the one from Scaled Agile Framework you can download here: SAFe Lightweight Business Case.

JIT conecpt is here applied because the information of every initiative, starting from the Funnel up until Analysis columns, is deepened incrementally according to customer needs (what arrived in the Funnel) and the effective capacity available.

Nothing is worked preventively and stays parked somewhere waiting for something to happen.

Ok, but what about WIP Limit? Well, in Portfolio Management we want to limit WIP because letting initiatives proceed through the kanban system is costly. This is why the Review and, moreover, Analysis columns are WIP Limited.

The Review phase is definitely lighter than Analysis. Usually the review is done by the portfolio management team plus some SME (Subject Matter Experts) and it does not last more than hours. Analysis could last days (for some very big programs even weeks), and it is more resource consuming. This is the reason we want to WIP limit more the latter.

Yes, now you should be ready to reason about prioritization through WSJF, GO/NOGO decisions, management of Portfolio Backlog and finally how to match capacity with demand when it’s time for initiative to be pulled into development….but these topics will be covered in next posts.

Enjoy! 🙂

Why (What? How?) you should Embrace Agile and Lean, to Manage your Portfolio

Lean and Agile are great approaches to increase effectiveness in Product Development and in Project/Program Management. What could be the most important things to do, to improve the development of your products and services?

If you are managing your portfolio of projects using the traditional way, probably you encountered several of the problems listed below.

What? You are already using Agile for Product Development?!

Well, even in that case, if you are stil running you portfolio in a old-fashion traditional way, you will find yourself creating local sub-optimization that, in the very end, will still lead the whole system to create waste and delays.

So, let’s see the reasons that should convince you to use Lean and Agile also at the portoflio level, what to do and how to embrace them.


Is your organization suffering from one of these?

  • Everything is top priority (means no priorities)
  • Projects’ effort is always big one. No short releases, neither MVPs (Minimum Viable Products)
  • Too many simultaneous projects
  • Too much time passes from ideas generation to product creation
  • Waste coming from multi-tasking is huge and not visible
  • Technical work is hidden and difficult to explain/justify
  • Too much interrupting work
  • Lack of visibility of how strategic goals are pursued through initiatives and related priorities, etc.

Well, those are symptoms that your portfolio management needs to be rethought…and not only in terms of practices or tools or techniques.

The most important thing to understand and to work with, resides just beneath the surface: values (and related principles) that drive decisions, behaviors of the people involved in portfolio management.

These are: openness, trust, commitment, focus, collaboration, courage.

Why Agile/Lean Portfolio Management?

This approach, if well understood and applied, will always lead you towards how to produce real and effective value for users: VOC (Voice of the Customer) is paramount.

It strongly organizes work around Value Streams (derived by analyzing VOC) and makes the process flow visible and transparent. Everything is thought to avoid waste. This is done by using pull systems to avoid over-production, limiting WIP (Work In Process), always stressing the importance of quality and making Continuous Improvement a pillar of the whole process.

Visualize your Value Streams

First of all, you need to visualize your Operational Value Stream:

how you are producing, or will produce, value for your customer, visualizing the systematic steps that create value and who is involved in this process, from concept (order) to cash (delivery).

Now, is time to see what systems are used, teams are involved and what features allows the organization to release value through that Operational Value Stream. This collection of teams and systems are called Development Value Stream.

Actually, identifying the people, teams, systems involved and making them consistent and cohesive, is a pillar of Lean/Agile Product and Service development, because the porfolio will be developed around these development value streams and, thus, around these long-lived teams: cross-functional teams which permanently work on same product lines or suites of products.

This concept is a core one when it’s time to talk about capacity. In Agile Portfolio Management, in fact, the smallest unit of measure is actually the team, not single individuals, neither pool of resources assigned for a predetermined amount of time and then moved to other projects (traditional project management).

Funding shall be also arranged according to these value streams, assigning dedicated budget: one budget to one value stream.

Well, in order to start the journey, you need to assess how your portfolio is managed in terms of numbers of project executed, duration, money spent, people and system involved, value delivered, available capacity, etc.

This is a necessary step in order to create the baseline against which to measure the effectiveness of the new approach.

Lift-off the Program/Portfolio Management Team

According to the analysis and the assessment above, you should know who should be part of the team. This team is, again, cross-functional and shall have senior leaders able to make effective decisions, coming from the different organizational areas impacted: IT will obvioulsy be represented (Demand? Architecture? Engineering? Q&A?), Business and others areas as well.

This team shall dedicate some time to create the right Mission, Vision, Objectives and Success Criteria for the portfolio management; this is a very important moment where people start to collaborate and to create team working agreements that specify for example:

  • the cadence and frequence when the team meets to work on the portfolio and for how long
  • decision making process
  • roles and responsibilities within the team
  • communication tools, channels, etc.

We usually use the Lift-Off Lean/Agile model to launch these teams.

Again, collaboration, open communication and willingness to work together is key to the success of the initiative.

Agile/Lean Portfolio Management Process Definition

Now is time to define which process (as much lean as possible) to put in place.

This in order to gather any new idea or initiative born in the organization and let them mature in terms of understanding of needs, possible solutions or approaches, any high level analysis of related costs and benefits, to finally arrive to a GO/NO GO decision for the implementation.

The process shall take also into account how to match the demand with the available capacity; here is where the Lean Pull and WIP Limit approaches, come into play.

Lean Portfolio Backlog Prioritization

Lean obsessively fights any waste.

A great concept that helps to avoid spending money for something that has small value, is the Cost Of Delay (COD). It tries to answer to this question:

how much does it cost to your organization, to delay a project in terms of business/user value, time criticality, risk reduction and enablement of new opportunities?

The COD, then, can be divided by the estimated duration of the project, which is the Wighted Shortest Job First (WSJF) that SAFe suggests to be a great tool to prioritize your portfolio backlogs.


Now it’s time to build your Kanban board which reflect the process above. SAFe suggests the following columns/statuses which are, actually, a great starting point.

The Portfolio team uses the board to visualize the work and the relative flow and cards to show the most important information of each initiative. Every column represent a status of the process:

  • Funnel: every new request, idea, initiative arrives here. They are arranged like a queue (FIFO). A standard, lean, minimalist template is used to describe the initative in order to be inserted into the funnel (everything is short and high level: description, top N feature, benefit expected).
  • Review: every initiative is, here, quick reviewed to see everything is clear, understood and well described. A very raw estimation of COD and relative effort is done in order to have a first prioritization.
  • Analysis: during this phase an Agile Feasibility of the initiatives reviewed in the previous column is done, in order to describe high level: the overal scope, architecture, estimated effort, expected benefits, risks, systems and teams involved, etc. The feasibility is run using Scrum and a virtual cross-functional team is formed that has the final objective to create a lightweight business case that contains the information above mentioned, which helps the portfolio team to take a final GO/NO GO decision.
  • Portfolio Backlog: every initiatives arriving from the previous column analysis, with a green light (GO decision), is introduced into the backlog, which is prioritized according to WSJF and here awaits for enough capacity from the teams to be implemented.
  • Development: this columns show everything that is under development
  • Done: all the initiatives that are finished and put on production are reported into this colums.

Well, we saw many things, but many others are necessary to have an Agile/Lean Portfolio Management in place (e.g. pull system, pull policies, limit WIP, buffers and definition of done, information on cards, definition of value, etc.).

So, let’s discuss it again in one of my future posts.

Be good 🙂

Back to Basic: User Stories and Acceptance Criteria

Every new user story presented to the team for development, must be accompanied with a set of user acceptance criteria which can drive development and testing.


Acceptance criteria is a great tool to ensure that the product being developed is actually what the Product Owner wants. Every user story is accompanied by a set of criteria that specifies how it will be tested and verified, in order to be accepted.

The concept behind acceptance criteria, hence, extends itself to the fields of user acceptance and testing activities and in general it means that every endeavor in developing must be guided by a specification of how it will be tested.

Often it happens, indeed, that if no acceptance criteria have been specified, developers finish to code, pass it over to tester and Product Owner for testing and acceptance phases, which reject it because it doesn’t satisfy their expectations.

Even more discouraging is when the story is rejected because of some minor issues caused by misunderstandings.

The trick here is to start in the right direction from the very beginning, that is when the Product Owner presents the stories during the planning meeting.

Let’s take the user story below as an example.

As a home banking user 
I want to make a money transfer 
So that I can pay the loan even if the bank is closed

To specify the user acceptance criteria (UAC) I like to use the GWT (Given When That) syntax, which is explained below:

Given [a specific condition] And [...]
When  [an event occurs] 
Then  [outcome] And [...]

Now, let’s see three basic acceptance scenarios which can be used to test and accept the user story above.

Scenario 1

Given that the account balance is2.000,00
  And the user is trusted
  And the beneficiary bank account exists,
When the transfer amount is800,00
  And the security operation code is correct,
Then the bank should transfer € 800,00 to the beneficiary 
  And the account balance should be updated to € 1.200,00

Scenario 2

Given that the account balance is500,00
  And the user is trusted
  And the beneficiary bank account exists,
When the transfer amount is800,00
  And the security operation code is correct,
Then the bank should not operate any transfer
  And a message must displayed saying there are insufficient funds

Scenario 3

Given that the account balance is2.000,00
  And the user is trusted
  And the beneficiary bank account exists,
When the transfer amount is800,00
  And the security operation code is NOT correct,
Then the bank should not operate any transfer
  And a message must displayed saying the code is incorrect

With this information available, developers and testers could immediately work together to refine the behavior of the functionality.

Thus, the tester can work on test cases and scenarios and the developer has a clear understanding of how her work will be verified and tested; she hence will develop only the minimum amount of well-written code to make all tests pass.

Simplicity actually starts from here: do your remember the Agile Manifesto principle?

Simplicity–the art of maximizing the amount of work not done–is essential.

Simple, isn’t it?!

Speaking at Italian Agile Days 2016

Very glad and proud to be one of the speaker of the Italian Agile Days conference, which will take place in Pavia November the 19th.

The talk I am proposing is about how to accelerate Agile transformations by applying the XLR8 change management model by J. Kotter, beside any agile scaling framework chosen. A great tool which strongly leverages principles like mobilized leadership, cross-functional teams, strategy networks and agile as well.

So, see you there 🙂

To change or not to Change? When Resistance slows down your Transformations

Everything in nature tries to maintain its equilibrium status.

Everything in nature tries to maximize benefits, against costs.

Change is “expensive”. Modifying any habit, approach, behavior, does cost. It costsmoney for organizations, it costs energy for human beings. It takes time for both.

Daniel Kahneman in his book “Thinking, Fast and Slow” explains that our brains are comprised of two parts, characters: one that thinks fast (System 1) and one who thinks slow (System 2).

System 1 operates automatically, intuitively, involuntary (e.g. driving, recalling our age, etc.). It operates on heuristics, which may not be accurate. This consumes small energy, it is almost effortless.

System 2 is used when concentration, focus, reasoning are needed and hence it deliberately slows down its rhythms.

This is used when something new needs to be faced, which not allows to jump to quick conclusions and solutions (e.g calculate a math problem, choose how to invest money, fill out complicated forms). Here the system spends much more energy to operate.

Habits rely on experience and heuristics and are executed by System 1. Changing habits, on the other way, uses System 2.

Furthermore, is far easier to establish new habits than changing old ones. This because the latter requires, firstly to dismount past ones, secondly to build up new ones on that.

So, changing well-established habits, cost even more.

Well, this is the first motivation on why human beings resist to change: it costs much, much, much more, than not doing it.

But, there is at least another reason, even more important, which consciously or not, drives resistance; it has to do with fear. The change could threaten us in our social or professional position, stature, power.

Fine, but how could we recognize resistance?

Resistance could be acknowledged by verifying active responses to change stimulus (complaining, being negative or destructive, etc.) or, more tricky, passive ones (ignoring, not attending to meetings or replying to e-mails, not being committed, avoiding doing activities or making any decision, etc.).

Both the two strategies are somehow simple to address when confronting with a single person. But what if the organization or part of it, is resisting to change?

Organizations are systems.

Any system has just one single objective: no matter what happens, it strives to maintain its internal state of balance.

That state is called status-quo: when a system reaches a stability in which everything is familiar and predictable. Everything in that state can be somehow categorized and managed accordingly. Surprises are rare.

Every person being part of that system, feels himself safe and protected and does not want to change. Remember, change costs effort and brings uncertainty.

But, to remain competitive organizations shall change. A big mistake organizations make is to decide changes top-down, “pushing” it from above.

When a change is so-called “injected”, every part of the system could react, each, in different ways: some by visibly fighting against it, others ignoring, still others delaying, mitigating or even initially “encapsulating” the change, but finally “rejecting” it, with a satisfied grin.

Managing such a resistance could drain all energy of any good change manager, coach, manger, even CEO.

Before managing resistance, organizations, should “manage” involvement.

They must learn how to involve people in order to be supported and helped in intercepting any big opportunity and create the underlying change vision, having employees on-board from the very first moment.

This ever-changing world needs diversity, passion, motivation, creativeness, inspired leadership to be totally understood. And the more the people being part of this “game”, the more the possibilities to be successful.

Organizations cannot accelerate their capacity to change and innovate without those ingredients. What is needed is what J. Kotter in his book XLR8 (accelerate) callsmobilized leadership: people who, guided by a strong and inspiring vision towards the change, are empowered to take action and to self-organize to change the old ways of working.

A feather (Nexus) for scaling Lean/Agile Product Development

Scaling Agile is fascinating and not trivial, at all. Many framework exists, SAFe for example is a famous, organic and somehow quite structured one that allows to scale agile within the whole organization through its four layers: Team, Program, Value Stream, Portfolio.

That structure can be overwhelming when applied to small programs and when there’s no need to scale up to the strategic portfolio layer

In that case Nexus, more light-weight, can be used.

A Nexus, as a generic definition, can be seen as the means of connection between things/groups linked together, which represents a whole that delivers value.

That definition is very interesting, because it stresses the concept that value can be delivered only through the cooperation and synchronization of the different actors forming the Nexus.

Nexus is the name that Ken Schwaber (one of the founding fathers of Scrum) gave to a framework which actually “extends” Scrum for scaling purposes. It has been thought for programs which combine from three to nine scrum teams and is strongly geared on Scrum fundamentals. Essentially, Nexus wants to answer and hence solve problems which always pop up when scaling Scrum: dependencies and integration issues.

Dependencies Issues

When three or more teams are working “against” the same product, they will for sure struggle with dependencies about requirements, how they are decomposed, prioritized and hence sequencing and distributed between teams.

Another interesting point about dependencies regards the knowledge of the team members. It happens frequently that, despite the willingness to have T-Shaped team members (generalizing specialist) – which are specialized in a specific domain (e.g. front-end developer) but also able to cover other roles (e.g. tester) – they, however, have siloed knowledge that often creates dependencies between teams.

Then we have technical dependencies more specific to source code and how it is managed through repositories, version controls and other artifacts more related to testing.

Integration Issues

According to the Agile Manifesto principles, we want to deliver working and valuable software every sprint. In a program with more teams we need to keep in mind that integration will happen putting together the different potentially shippable incrementscoming from the teams, into a single product increment.

This is hard work indeed and leaving it “just” to teams’ self-organization, could be a real challenge. Nexus wants to solve these problems, starting from “pure” Scrum and adding just the necessary additional roles, events, artifacts and rules to make this work.

This is the Nexus life-cycle.

Considering that Scrum is the corner stone, the foundation pillars, let’s see what is added or changed.

Nexus Integration Team Entity

An important entity is added, which is called the Nexus Integration team.

The team is formed by the Product Owner (look, we have just one Product Owner for the whole Nexus), the Scrum Master and one or more team members, eventually shared between scrum teams. The composition of this team could change, if necessary, according to the necessity of the product development.

The main responsibility of this team is to address any integration issue the program is facing; sometimes it could even work on P.B. items that are related to integration.


We obviously have one product backlog which is owned by the Product Owner. This product backlog is refined and stories pulled by teams.

A new artifact is the Nexus Sprint Backlog which is the formed by the Nexus Sprint Goal and the collection of the various team Sprint Backlogs and goals.

Lots of use of Visual Management is recommended in order to see the work to be done and every dependency of the program.

The Nexus sprint backlog hence should visualize all the items above described.

Product Backlog Refinement

I want to start with this activity because in, my opinion, is the most understated event in standard Scrum, thus leading to many and big problems.

In a program with more teams collaborating and insisting on the same product backlog, this is even more important. Nexus framework does not identify a specific event, as Scrum, but states that refinement should happen according to complexity and rhythm of the program.

The main objectives are:

  1. decompose coarse grained items in more fine ones ready to be developed in the upcoming sprints,
  2. think on what items of the product backlog will be pulled by what team,
  3. minimize dependencies.

A first part of the meeting should be dedicated to refinement and the second one to dependencies minimization.

Nexus Sprint Planning Event

Product Owner gives knowledge and contexts about stories that should be developed, according to the previous activity of backlog refinement.

Teams validate and prioritize the stories they pulled and after a discussion that aims to finally consolidate the high level vision of the sprint, each team execute its own sprint planning. It is highly recommended that the sprint planning for each team happens in the same spaces in order to immediately address and discuss any dependency.

The event concludes when every team finishes the forecast for the sprint and a big, overall (Nexus) visualization of sprint backlogs and dependencies is done.

The Nexus sprint goal must be confirmed by each team sprint goal.

Nexus Daily Scrum Event

This events happens just before the the team daily scrum. Nexus Sprint Backlog is used to guide the meeting. Status of integration is the main topic.

Representatives from the development team should participate with the Nexus Integration Team, to identify, discuss and address any integration or dependency issue. Decisions and work to be done to solve problems, must be reported in the daily scrum of each team by the respective representatives.

Nexus Sprint Review Event

This event replace the one from each team. The integrated product increment is showed to stakeholders to gather feedback.

Nexus Sprint Retrospective Event

The event is divided into three separate parts, but in general focus is on: Integration issues, Technical Debt, Work Undone.

During the first part teams (or representatives) meet to discuss main issues and problems which have impacted the program. Focus should be on impacts across two or more teams.

The second part is held by each team according to Scrum; input from previous part should be addressed accordingly.

In the final part the teams (or representatives) meet to share decisions or any new information. They also decide on how to visualize improvement actions.


My experience taught me these lessons.


Not always is feasible to have the whole team involved in Nexus events (see also LeSS Huge). In those cases representatives should be sent. Well, these guys are so important and you need to think and select them according to their skills, knowledge, communication and negotiation abilities.

One PO

Nexus asks for one PO, just one. Every team shall find the best solution to leverage that role and adjust, not having her always in its room. Once more, you need to think how the team could ease and facilitate this discussion and relationship (see representatives above).

Integration team

This team is in charge to mainly face and lead the resolution of integration issues. That’s its primary objective. You need to spend some time to think who should be part of it, about the roles of the Scrum Master and understand how the PO should behave within this team and with other Scrum teams.

One DoD (Definition of Done)

In Scrum definition of Done is an agreement the team makes to decide when the work can be definitely defined as done. This has activity that must be finished and has to do with coding, testing, acceptance, user documentation and the like, anything necessary to ship a working feature.

Well, in Nexus teams should agree to have one DoD in order to facilitate (again) integration and minimize dependencies.


This is so important, moreover when you are working with several teams on the same program. Time taught me that events like planning, refinement, review and retrospective at Nexus level, MUST be done together in shared spaces or, at least, leveraging the best technology to keep team in touch via IM, Webcams, VDC, etc.


Another error teams do frequently is to underestimate the power of visualization.

I teach my teams to have a Nexus program board on which report the sprint backlog(s), any dependency showed via red stripes (SAFe here is master) and visualizing every impediments via post-its and a dedicated board.

Finally if you have:

  • teams that are already good with Scrum,
  • not many teams working together to build one product
  • not too many external dependencies
  1. not too much complexity on how to sync and map the program to Enterprise structure and processes (or the Enterprise is guan Agile one)

well, in that case, Nexus could be the right choice….otherwise, SAFe comes to play.

See you guys!


#BizTriathlon. The Lean Strategy Validation Canvas

Last Saturday I participated to the Agile Business Day conference in Venice. It was a day very well spent because of the speakers and, obviously, of Venice too!

Actually, I was one of the speakers :o) and presented a talk called “Business Triathlon. How to change, innovate and produce value quickly, in environments subject to constant turbulence.“.

The model I presented, is mainly focused on how to remain competitive (Change the Biz) continuing to deliver value and results (Run the Biz) with constant pace. It incorporates four major approaches: Lean Strategy, Lean Start-up, Agile and Change Management.

This post is mainly focused on the Lean Strategy topic and presents the Lean Strategy Validation Canvas.

I use that tool with customers that wants to validate the vision of the organization against its real position in the market and finally come out with strategic themes and objectives, which can thought as pillars of the strategy.

But first let’s take a closer look at the whole model.

I used the metaphor of triathlon for many reasons you can find in my presentation here, but the core concept is that we can somehow link the three domains of the model, according to main characteristics of the triathlon disciplines:

  • Swimming: Strategic, Explorative, Resource Balancing
  • Cycling: Emergent Strategy/Tactic, Technical, Tear-And-Go
  • Running: Pragmatic, Consolidation, Constant Pace

There’s actually another important “discipline” in Triathlon that someone calls the 4th discipline, which is the transition from one fraction to the other. It can actually thought as a Check Point, where your body adapts and you also change your equipment to face the next fraction. A kind of transformation happens.

The #BizTriathlon model maps this with Change Management approach and theXLR8 model from J. Kotter is the best approach which could fit.

This post regards the formulation of a Strategy (swimming), using a lean approach.

Usually senior management agrees upon a high level strategy for the organization, based on company’s vision, values, objective and scope.

Wishful thinking and complacency must be avoided, relentlessly. This is why the management should examine in detail, the organization strengths and possible opportunities, weaknesses and related threats, resources available and internal capabilities.

Having this clear picture in front of you, makes you more confident in deciding anything, moreover the company’s strategy.

When a strategy is well declined and agreed, it’s time to analyze and define the initiatives able to realize that. The canvas helps a company who wants to go into the above described process, to finally create its own strategy.

Let’s take a closer look into the canvas.

First of all, it’s worth specifying that this tool can be used for every kind of organization, department, business unit, group, etc.

We have five quadrants, each one marked with numbers which indicate the compilation sequence:



The four most important core values must be reported here. These values, should guide the realization of and be reflected in, the vision and hopefully they drive every decision regarding the formulation of the strategy.


An inspirational vision of the organization must be formulated, based on core values, which will project the organization in the future, giving direction and alignment.


A SWOT matrix is used to position the organization to the market according to internal strengths and weaknesses and opportunities and threats.


The organization vision, opportunities to exploit, threats to avoid and/or mitigate, all together drive the identification of strategic themes, which are itemized business objectives, providing context for decision making.


Finally, high level strategical objectives must be stated using the SMART model and must match one or more strategic themes.

I use this tool to lead specific workshops to formulate the organizational strategy. Once the management fully agrees on results, it’s time to start “feeding” the Lean Portfolio.

But, actually, this is the next step in the #BizTriathlon model, which I am going to cover in one of the next post.

Well, remember, you’ve just started your triathlon race and you are swimming with many others fierce competitors….

Enjoy :o)

WordPress Themes