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)

#BizTriathlon. How to change, innovate, and produce value quickly, in environments subject to constant turbulence

Structured organizations today are not keeping pace with this incessantly changing world. The Business Triathlon (Lean Strategy/Start-up, Agile and Change Management) could be the solution.

Yesterday at Agile Business Day conference in Venice, I had the possibility to present my talk about Business Triathlon.

As I wrote here I practiced Triathlon for many years and found many parallelisms and learning, which I apply in my everyday life, personal and working one, and wanted to share through that talk.

The trigger for the #BizTriathlon model was the thought and concrete experience that systems, structures and cultures built in the past years, are no longer able to keep up in a world, our world, which changes at a pace never seen before. Organizations now compete in global markets whose business models are changing rapidly driven by new paradigms (Start-ups, share economy, 3d printing, etc.).

The imperative is to evolve rapidly, constantly, always watching the market and its evolving trend.

How companies can remain competitive and continue to produce results on the one hand, and simultaneously changing themselves in the midst of this constant turbulence?

A model that works very well is to one of start-ups: adaptive organisms from birth, lean, used to quickly change according to market demands and to feedback from their users. Those are companies whose cultures are strongly anchored in Lean and Agile methodologies, whose leadership models are collaborative rather than managerial, where to the hyper-specialization of functional silos fragility, is the preferredAntiFragile model of cross-functional teams.

How you can apply those models to complex organizations such as banks, insurance, telecommunications, public administration?

The Business Triathlon Model (#BizTriathlon) wants to give answers to questions like these:

By using an iterative, rolling-wave and inspect&adapt approach, the model goes through the definition of a high level strategy (Lean Strategy and Lean Portfolio)approach, whose underpinning hypothesis are constantly checked against the reality of the market (Lean Start-Up) and when a sustainable business is finally found, it is digged in through the iterative/incremental approach (Agile) in creation of related products and services.

Embracing those methodologies for organizations means lots of changing in terms of culture (value, principles, habits). This is the reason why the #BizTriathlon model useschange management to help individuals make successful personal transitions resulting in the adoption and realization of change and XLR8 from John Kotter, to create virtual networks within the organization to modify the old structures, process and habits from the within.

Here are available the slides of my talk.

Enjoy! 🙂

The Entrepreneur and the Triathlete

What keeps together an Entrepreneur and a Triathlete?!

In my previous working experience I have been an Entrepreneur. I run my own company in the IT field, together with other two partners.

More or less in the same period I started to practice Triathlon (swim, bike, run).
Because of the demanding sport discipline I choose, at the time I used to go swimming during launch breaks and running or cycling early morning or late afternoon before or after work.

So it happened every time that thoughts about my job, my company and my professional development, got mixed with fatigue and thoughts about races, events, athletic training, finding myself look for similitudes, parallelisms and patterns between being and entrepreneur and a triathlete.
This is what I learned.

As a Triathlete

You have to be multi-disciplinary.
You have to be good enough at swimming, biking and running and putting all together, in a single race: your heart, muscle, head, must be correctly tuned on that.

Furthermore, you should not forget to take care of what is called the 4th discipline of triathlon: the transition phase from one to the other discipline, where you could lose precious seconds or, even worse, concentration.

You have to study the basics and advanced concepts as well of each discipline having them their own rules, rhythms, techniques.
You have to study on how to train, what nutritional habits are allowed and, obviously, how to swim, bike and run, faster than the wind.

You have to practice and learn, a lot.
Fluency and good performance will arrive only after hours spent watching at the black stripe on the bottom of the pool when swimming, or the white one of the roads you go through when running or cycling.
Modifications must happen to your body and mind and that needs time and dedication and perseverance.

You have to be bold.
Triathlon is not impossible, either not trivial. Swimming in open waters, surrounded by dozens of other crazy athletes, cycling at high speeds, up and down from hills and running miles under any weather conditions, implies courage.

You have to be passionate: no one can resists to months of training, doing several workouts per week, if passion is not there.

You have to be disciplined in following the right diet, training programs, practicing and continually improving the execution and technique.

As an Entrepreneur

Being a successful Entrepreneur means to have plenty of great attitudes.

Many of them are related to the working field the company is positioning its business, many others are common to any specialization, field or sector.

As I wrote in one of my previous post, it seems that effectiveness, adaptability andopenness are inalienable attributes for entrepreneurs.
But other very important attitudes are the ones above described also for triathletes.
And, you know what?! The more you train them by swimming, biking and running, the better you could reuse when leading your own company.

A great Entrepreneur is multi-disciplinary. She needs to be very competent in the field she is working but, contemporarily, she must proficient and efficient in dedicating herself also to marketing, sales, accounting, human resources and others very important topics, in order to let her company grow fast and healthy.

Obviously remaining competitive is a must, no matter the field and the business you are working; that means to be a learning machine: reading and studying hard should be routine.

Then, any new idea or concept learned must be tested by practicing them in the real life.
Here is where concepts like Lean Start-up come into play, thanks to theBuild/Measure/Learn process which leads to the creation of Minimum Viable Products (MVP) that are launched fast and often into the market, through an iterative and incremental approach. 

Every Entrepreneur is passionate about her idea, the work she is doing and how to transform it into real products or service. Passion helps to remain focused on the goal even if it is needed to change means or strategies to reach it.

And finally yes, she must be disciplined because being an Entrepreneur does not mean to dedicate herself only to things she loves the most; many others, less fascinating, things such as paying taxes, meeting accountants to review balance sheet or lawyers to discuss contracts and the like, must be done and, for sure, those need even much more discipline and dedication.


But, there’s an important thing that strongly distinguish an Entrepreneur from a Triathlete: the latter wins the race by counting only on herself, the former can win only by leading groups of people toward a clear and inspiring vision.

That’s remind to me an old African proverb…


Train your muscles to help organizations improve their business agility

How Agile & Lean transformations help organizations in achieving business agility? What are the seeds, foundations, pillars that sustain this goal?
How an agile change agent can help those transformations happen?

Agile and Lean are effective methodologies which can help in achieving business agility by optimizing the processes involved in the creation of value for customers (Lean) and aligning people, giving them context, vision and resources, to be responsive and creative to build innovative products (Agile).

Fine, but what does “business agility” means exactly?!

Business agility is the “ability of a business system to rapidly respond to change, by adapting its initial stable configuration” [Wikipedia]

This system must be responsive enough, to sense a change that is coming andreconfigure its internal structure, to adequately respond and thus finding a new stable and more profitable balance.

One of the crucial characteristic the system should have is resilience.

Let’s elaborate a bit more.

Business agility can be achieved by maintaining and adapting goods and services to meet customer demands, adjusting to the changes in a business environment and taking advantage of human resources.
Thus, agility is the ability of an organization to rapidly adapt to market and environmental changes in productive and cost-effective ways. [Wikipedia]

Human beings are  obviously the most important factor an organization has to leverage when it’s time to change.
This is the reason why the agile manifesto states “Individuals and Interactions, over processes and tools” as the first value to achieve agility.

Furthermore, when it’s time to change, many dimensions must be taken in the right account:

  • How will people react to this change (change management)?
  • What kind of leadership will drive the change (leadership models)?
  • How will decisions  be made (decision making framework and working agreements)?
  • What tools and techniques will be used to optimize processes and solve problems (lean thinking)?
  • Which approach can definitely help in pursuing opportunities and steering quickly to catch them (lean startup)?

One step further.

The agile enterprise is referring to an organization that utilizes key principles of complex adaptive systems and complexity science to achieve success. One can say that business agility is the outcome of Organizational intelligence. [Wikipedia]

Scaling agile across the enterprise means to enter the land of complexity, where no best neither good rules and recipes exist.

Well, given the situation, as agile change agents is mandatory for us to acquire knowledge and expertise in the following areas, considering this list as non comprehensive:

  • Change management (kotter, adkar, lean change, 7s, Satir, etc.),
  • Decision making (cynefin framework, problem solving, etc.),
  • Lean thinking (lean philosophy and tools),
  • Leadership (management 3.0, effectuation, etc.),
  • Agile  (Scrum, Kanban, XP, etc.),
  • Agile at scale (SAFe, DAD, LESS, Nexus, etc.)


So, see you there :o)

Getting a big and complex project off, from the starting blocks with Agile (DAD Inception)

What if the Agile project you are launching is a big and complex one?
What if the usual “2 days inception” are not enough to lift-off your project?

I love the Inception Deck from the Agile Samurai.
Yes, I really do love it because is a great set of agile tools you can use to explore the main dimensions of a project, in a completely new way respect to the traditional approaches: collaborative, using visual management and avoiding too much detail but with a great effectiveness.

It happens, however, that the project you are trying to launch, needs more understanding about scope, risks, architecture, etc. but you still want to avoid any big up-front analysis.

Well, DAD could help.

DAD is a hybrid framework that builds upon the solid foundation of other methods and software process frameworks. The framework adopts practices and strategies from existing sources and provides advice for when and how to apply them together. 

The product development lifecycle looks like the picture below:

At a first glance, DAD could seem a bit too process-oriented, too structured.
But, actually, DAD incorporates the Agile Manifesto, defines its own Disciplined Agile Values and Principles, is completely geared on the Lean principles and finally is strongly empirical.

DAD Inception Phase

One of the most interesting thing I found in DAD, is the Inception phase (or Iteration 0 or Warm Up).

I usually use that phase with big, complex projects to “manage” with Agile, which needs more information before to proceed with the construction/build phase.
This Inception phase could last from 2 to a maximum of 6 weeks (Ambysoft 2013 Agile Project Initiation Survey Results) and depends on the project nature and size.

The main objectives of the DAD Inception phase are:

  • Clarify the needs the project wants to satisfy
  • Define a clear project (and product) vision
  • Identify a feasible technical solution
  • Define the strategy and a high level roadmap
  • Build the team and set-up the necessary technical environments
  • Involvement and buy-in of the stakeholders

I use to execute this phase using scrum, too.
The organization must identify the Product Owner who will be in charge also for the Construction phase, and a Scrum Master is needed as well to help people remain focused.
Then, the work proceeds by running sprints (one-week length) and sticking to the scrum events in order to plan for the work, keep learning, demonstrate the work done and retrospect the results and the process utilized as well.

Every phase in DAD is divided in three specific moments called: Coordinate,Collaborate, Conclude.

The Coordinate moment provides for the creation of the inception team, a first draft agenda definition for the first week, just to have some guidelines and to involve the right stakeholders since from the beginning.
This agenda, then, will be discussed by the inception team and adjusted according to the real needs once started.

The Collaborate moment is when the learning phase starts and work is actually done.
Here the team is finally built, Scope and Architecture are high level envisioned, any necessary feasibility spike is done, any initial issue, risk or impediment is identified and addressed in order to facilitate the project start-up and a first high level estimation is done to have a range in terms of effort that could be spent for the project.

Then, the Conclude moment, aims to communicate the outcomes of the inception sprints to the relevant stakeholders in order to have their consensus.

I would like to spend just a few words regarding the inception team.
Usually at this point in time of the project, we probably do not have yet available the whole budget for the project. The project, probably, will be definitely confirmed with the information gathered during the Inception.

This means that the Inception team won’t be formed by the whole development team but probably by one or two senior team representatives, an architect, the product owner, and the necessary SME (Subject Matter Expert) that could be called on-demand according to the workshop sessions (high level envisioning of architecture, scope, U.X., DB, etc.) scheduled in this phase.

To summarize, during those sprints, the Inception aims to deliver an high level view of these items:

  • Vision
  • Program/Project Objectives
  • H.L. Roadmap
  • First draft Product Backlog version
  • H.L. Architecture
  • H.L. UX Artifacts
  • H.L. Estimation
  • Issue Log

What to do next?
Weel, it’s time to bring on board all the team members, have a 1 or 2 days lift-off and finally start to build the system.

Oh yes, obviously using Agile.

WordPress Themes