Architecture - Hybris Lifecycle Framework
Architecture - Hybris Lifecycle Framework
for Commerce
The SAP Hybris Application Lifecycle Framework
(ALF) for Commerce is the culmination of many
years of experience, knowledge, and know-how
within our specialist SAP Expert Services teams
who have been deeply involved in a huge variety
of SAP Hybris Commerce projects across the
world since hybris was founded in 1997.
ALF for Commerce provides a set of frameworks and recommended practices that can be
used from the beginning of a customer’s first SAP Hybris Commerce implementation project,
all the way throughout the solution’s subsequent on-going lifecycle. These frameworks and
recommended practices offer guidance around project management, architecture,
development, quality management, requirements management and other important
topics.
Structure
ALF for Commerce is structured in three main areas:
Upgrade the platform and selected modules to the latest released version
Migrate specific solution modules, data model in database and business data
From a people perspective, every customer is different, has different requirements, different
ways of working, different standards, different internal governance processes, etc.
Additionally, there are multiple different approaches and methodologies to delivering
implementation and upgrade projects, each with their advantages and disadvantages, and the
‘right’ approach being different depending on the project context.
Therefore these projects need to be managed differently and no two projects will ever be the
same. The scope, size, and duration of these projects will also vary significantly from project-
to-project and customer-to-customer. Some projects are so large with so many dependencies
and work-streams, they often need to be managed as programs, whereas others are fairly
small and self-contained. So although projects share similarities, they are also very different.
However, underlying all this variance, there is a commonality in terms of how all these
projects hang together, and a set of practices that can be applied. Together these form the
Project Delivery Framework.
What is a Project Delivery Framework?
A framework is a set of practices and structures. The SAP Hybris Application Lifecycle
Framework (ALF) for Commerce is a set of practices and structures focused on the
whole lifecycle of a solution built on Hybris Commerce, and within that the Project
Delivery Framework is a set of practices and structures focused on the project aspects
within that lifecycle.
This shows an initial implementation project to build and deliver the solution to the live
environment so it’s accessible by end users. This implementation project can be delivered as
a single project or multiple smaller projects. Typically it’s then followed by subsequent smaller
projects throughout the lifecycle such as integration to enhance the solution over time as the
business needs evolve or upgrade to bring the solution to latest Hybris release.
In this section of the SAP Hybris Application Lifecycle Framework (ALF) for Commerce, we
will discuss this Project Delivery Framework in more depth and explain how it can be used in
the different contexts of each customer.
The diagram above shows a high-level example of a project scheduling plan with an initial
implementation project split into three releases, followed by an integration project and a
migration project. The first release of the implementation project is then expanded to show the
phases.
The names of the phases shown here are based on the naming convention in DSDM’s Agile
Project Management Framework, however, they could easily be named differently. It’s the
activities and deliverables within the phases that are important.
The Project Delivery Framework makes a distinction between projects and application
management, where:
Projects are blocks of distinct work with the aim of delivering a certain scope within a
certain timeframe for a certain cost (and an assumed level of quality).
Application management is the continuous support, operations, and maintenance of
the live solution once it's been deployed to a live production environment and is being
used by end users.
Projects typically run sequentially delivering into the parallel application management stream.
This starts with the initial implementation project, often split into a set of sequential releases,
followed by ad hoc or continuous projects in parallel to application management activities,
continuing on an on-going basis until the solution is eventually decommissioned. Together
this cycle of projects is called the application lifecycle.
There are also different types of projects, not just the initial implementation project. There
may also be subsequent functional development projects, system integration projects,
internationalization projects, migration projects, infrastructure projects, etc. and some projects
that are a mixture of types if combined.
The Project Delivery Framework can be used as a reference for all of these projects and is
adaptable to different software development lifecycle (SDLC) methods such as Agile, Rational
Unified Process (RUP), or waterfall, and it's applicable to Project Management Institute (PMI)
and Project Management Body of Knowledge (PMBOK) best practices.
The framework is neither rocket science nor revolutionary. Its intention is to define a common
and generic set of practices and approaches that can be readily understood and used as the
basis for a variety of more specific frameworks and practices that can be selected based on
the appropriate project context.
Many customers and partners will have their own methodologies or delivery frameworks,
created and suited for their own contexts and strengths. Some will be based on common
SLDC methods, some will be hybrid approaches, or based on less well-known SDLC
methods. There's no right or wrong approach. It's all down to the specific context of a given
project and organization.
Therefore given the variety of contexts, it's important that the Project Delivery Framework is
equally understandable to someone from a waterfall background, or RUP background or
someone using a hybrid approach with their own naming conventions. So each phase within
the Project Delivery Framework is within a generically named block:
Discovery & planning - the where/why/how/what of the project, including scoping,
architecture, planning and costs
Design/build/test – the building of the solution, whether iteratively (e.g. Sprints) or
broken down into sequential design/build/test sub-phases
Deploy – the preparation and delivery of the solution into the live production
environment.
Releases
A large project is often broken down into slices or increments called a 'release'. The
size of a release can vary depending on the context. An example would be breaking down
a 12-month project into 2-4 smaller releases of relatively equal duration, with each release
containing all the project phases as shown below:
The set of sequential phases would then start again with the next release, although the initial
up-front Initiation phase that assesses the project feasibility, business case, high-level
scoping, etc. is often not required as the outputs of the previous Initiation phase are still valid.
Smaller releases can help to reduce project risk, improve time-to-market and give more
immediate visibility to the business and end-users, however, they need to be balanced with
the overheads involved starting/ending each release.
Alternatively, some organizations take this even further by utilizing Continuous Delivery
methods to enable continuous deployments to production on a weekly or even daily basis
rather than releases spanning weeks or months. However Continuous Delivery is not easy
and ideally needs to be built into the project from day one. It requires significant investment
and the business drivers need to be properly assessed to match the frequency of releases.
Not all organizations can properly handle or need such regular deployments.
Initiation Phase (Discovery and Planning)
The primary objective of this phase is the alignment between the customer and the delivery
team in terms of the why/what/how/when of the project. The customer could be another
organization or another department within the same organization. The delivery team might be
an in-house IT department or an external service provider. There might be a commercial
relationship, there might not. However, the high-level activities of this phase remain very
similar and include:
Ultimately the result of this phase is a go/no-go for the next phase to understand the project in
more depth, called the Foundation phase.
The primary objective of this phase is to establish firm foundations for a project from a
business, technical and project management perspective, and to enable all parties to have a
solid understanding of the scope/time/costs/risks of the project.
The phase consists of a series of onsite workshops with the customer and delivery teams,
plus key stakeholders and 3rd parties. The specific activities and deliverables of this phase
can vary depending on the methodology however they generally remain very similar (although
granularity will vary greatly between different methods, so waterfall will have much more
detailed requirements definition than Agile):
Usually, the result of this phase is a go/no-go for the build phase of the project, called the
Engineering phase. However, sometimes there is still too much uncertainty (technical or
otherwise) which prevents the teams from having enough understanding of the risks to give
the go-ahead for the full Engineering phase, which is essentially the go-ahead for the whole
project due to the very significant commitment of resources and people. In this case, teams
may want to proceed with a smaller, optional, Exploration phase.
This is an optional phase. It's only required if there remains a high degree of uncertainty or
risk following the Foundation phase. The primary objective is to explore those risks and
uncertainties in enough depth to provide the teams with the confidence to proceed with the
larger Engineering phase and essentially commit to the project.
Given that risks and uncertainties are project specific, they can vary widely, so the activities of
this phase will also vary. However, typically they are technology related, and often involve
the development of prototypes or proof-of-concepts. These can be throw-away or designed to
be reused if the project goes ahead.
These types of phases are more common on greenfield or build-from-scratch projects,
especially when using new or leading-edge technology stacks with challenging non-functional
requirements such as very high numbers of requests or data volumes. They are less common
when building a solution from a mature platform such as Hybris Commerce, however, an
Exploration phase can still be valid where needed, e.g. if using Hybris Commerce to build a
mission critical solution with non-functional requirements that exceed the boundaries of the
design criteria for the Hybris Commerce platform.
Typically the Exploration phase is relatively short in duration, just enough to provide
appropriate certainty to make a go/no-go decision for the project, starting with the Engineering
phase.
The primary objective of this phase is to design, build and test the solution to meet the
functional and non-functional requirements and the high-level architectural design defined in
the Foundation/Exploration phase.
The approach taken to develop the solution will vary significantly depending on the SDLC
method. Some methods will break this phase into small 2-3 week iterations called sprints
each with smaller design/build/test cycles (e.g. Scrum), others will have larger, more well-
defined design/build/test cycles maybe even with their own sequential gates and sign-offs.
For example, a waterfall approach would split this into three separate design, build and test
phases.
This phase will also include some form of acceptance testing, often planned as a block of time
at the end of this phase, however, sometimes acceptance testing is managed iteratively
throughout this phase. System integration, performance, and other non-functional testing are
also key activities of this phase.
Ultimately the end result should be a high-quality solution that meets the functional and non-
functional requirements and is ready for deployment to the production environment within the
Deployment phase.
Deployment Phase (Deploy)
The primary objective of this phase is to prepare and deploy the software produced in the
Engineering phase to the production environment, ready for use by end users.
The activities of this phase can vary significantly depending on the project context, however,
typically they will include:
Teams may plan not to take the solution live in the current release for business or technical
reasons (perhaps the customer is replacing an existing platform and there is only a subset of
the current, live functionality in this release), so this phase is not mandatory. However, there
are strong technical and business advantages to deploying early to test the solution in the real
“live” environment, even if it's a 'soft' launch (e.g. friends-and-family) with a subset of users.
Early feedback at this early stage can significantly reduce the risks inherent with a big-bang
deployment later.
Application Management
This workstream starts with the first deployment to production from the initial implementation
project, however, it needs to be planned from the start of the project to ensure responsibilities
are clearly defined and people are appropriately trained and enabled. The project team can
sometimes manage some of this workstreams responsibilities. However, it's often managed
by a separate specialized team.
Methodologies
There are various software development lifecycle (SDLC) approaches that have evolved over
the years to enable teams to manage this complexity and uncertainty and help them deliver
successful projects.
Here we summarize that evolution from Waterfall through Rational Unified Process and Agile
to help create an understanding of the different SDLC options for Hybris Commerce projects.
Waterfall
First, there was the predictive Waterfall method developed in the 1970s. This method was
characterized by a sequence of stage-gated (sign-off) phases: requirements, design,
implementation, and testing/verification followed by on-going maintenance. This
method is still commonly referred to as the ‘traditional’ SDLC method.
Since its development in the 1970s, the Waterfall approach has been used on a huge number
of projects and is still frequently used to this day, with its successes and also many high-
profile failures.
We attribute the sequential nature of the Waterfall approach to Winston Royce's 1970's paper
that defined stage-gated "Waterfall" model of the software process, similar to that shown
below:
Here the Waterfall method typically progresses as follows:
However, the paper was commonly misunderstood and actually promoted activities that are
not regarded as traditional Waterfall activities such as feedback cycles, prototyping and an
iterative and incremental approach (http://en.wikipedia.org/wiki/Winston_W._Royce).
However, these additional activities were ignored and the traditional Waterfall method evolved
as we know it today (as described above).
Critics of the traditional Waterfall method point to the fact that software requirements often
aren’t known in enough certainty at the beginning and/or that requirements often change
throughout a project. Both of which are counter to the big up-front requirements
analysis/design phases and the subsequent restrictive (and often expensive) change request
process this method requires.
Even if the up-front requirements are managed successfully, subsequently the customer isn’t
closely involved in the project until the end verification phase when the software is tested, and
by then it’s often too late to change anything. So customers risk not getting what they thought
they were getting.
With testing deferred to the end of the project, defects are also discovered very late. If these
are architectural or design defects, it’s often too late or too expensive to fix them.
From a planning perspective, the up-front fixed requirements combined with the sequential
critical path nature of the activities mean that if there is a delay in any activity or phase, it has
a direct knock-on effect on all remaining activities and phases. This often leads to cost and
time overruns. When this occurs teams often reduce the duration of the verification phase
(testing), which subsequently directly impacts quality.
Therefore it’s common for projects implemented using the Waterfall method to run over
budget, over time and with poor quality, particularly when there is a reasonable amount of
change or uncertainty.
In the 1980s and 1990s, in response to the failures of many Waterfall projects together with
the increased time-to-market pressures, iterative and incremental SDLC methods were
developed, including the well-known Rational Unified Process (RUP).
Like Waterfall, RUP recognized the importance of lifecycle phases. However, it was the first
method that also realized the importance of activities that overlap these phases rather than
being distinct activities within each phase as per the Waterfall method.
The diagram below shows the phases and how activities (represented by disciplines) occur
throughout multiple phases:
With RUP and the other iterative and incremental methods, there was a purposeful move
away from the big up-front requirements and design associated with Waterfall to a more
discovery-based approach with lighter-weight documents and models and an iterative
approach to development where requirements are discovered and elaborated in early
iterations.
The approach taken by RUP was to cater for all types of projects by providing a superset of
prescribed disciplines, artifacts, and processes. Unfortunately this has led to it becoming
labeled as a heavyweight method, because to be successful teams need to be highly skilled
in the RUP method to understand what they can discard from these disciplines, artifacts and
processes for their particular project without undermining the others that remain, which has, in
turn, led to teams leaving many things that they don’t need which directly increases both cost
and time.
So although RUP has been used successfully to deliver many projects, it’s also had its share
of failures due to unnecessary complexity and cost/time overruns.
Agile
In the late 1990s in response to the perceived heavyweight and overly prescribed approach
taken by RUP, lighter-weight adaptive methods were developed. Together they became
known as Agile methods, culminating in the Agile Manifesto created in 2001 that was a set of
practices and principles which define and underpin all Agile methods. These Agile methods
included Scrum and Extreme Programming (XP) among others.
Agile methods focus on delivering high quality, high value, working software quickly to
customers in an iterative and incremental fashion, accelerating time-to-market while also
being highly adaptable to changing business environments.
Agile methods take the opposite approach to RUP with its superset of project disciplines,
artifacts, and processes, and instead encourage teams to start with the minimum and only
add to them if necessary. High value, high quality, adaptability to change and low cost are the
hallmarks of projects using well-managed Agile methods.
Agile methods have become increasing popular in the last 10 years and are now used
successfully in organizations all over the world. For example, the Hybris Commerce platform
was successfully built internally using Scrum and other Agile methods, and these practices
and processes have been adapted as the platform and company size grew in size and
sophistication.
Over time, the various flavors of the Agile methods converged and now when people refer to
Agile they typically refer to Scrum usually combined with XP technical practices such as
continuous integration, test-driven development, pair programming, etc.
It’s great for continuous streams of development in a production-like mode for a company
producing software products but doesn’t cater for project environments with kick-offs,
requirements analysis, acceptance testing, deployment phases, etc. or corporate governance
processes.
It’s designed for small collocated teams, not large distributed teams.
It’s designed for internal teams and doesn’t specifically cater for commercial environments
where there are contracts and potentially multiple different organizations responsible for
delivering the solution.
So although projects using Agile methods have been very successful, there have also been a
significant number of failures, particularly when the above constraints are not adequately
being considered. Also, many of these project teams claim to be Agile when in fact they are
only following a subset of Agile principles or practices, or often they are actually following a
Waterfall approach dressed-up asAgileapproach (“we have daily stand-ups and a backlog,
therefore we are Agile”). For Agile methods to be effective and successful their principles and
practices are finely balanced as they are dependent and support each other.
Counter to many people's understanding, to be successful with Agile teams require a high
level of discipline and focus, and it doesn't mean throwing all process and documentation out
of the window. You will probably find more process in a properly executed and managed Agile
project than in a Waterfall project. However, those processes are there for a very specific
reason, and all add demonstrable value.
Although not as well known as the previous methods, DSDM (Dynamic Systems
Development Method) was originally developed in the UK in 1994 as a closed consortium of
several large UK organizations. They collaborated to create a project management method
called DSDM based on their shared experiences with Waterfall, unified process and other
SDLC approaches.
Members of the DSDM consortium were also involved in the origins of Agile and the creation
of the Agile Manifesto as they recognized the importance of leaner software development
practices within projects. Later the consortium was opened up to other members outside
these large enterprises, to grow and widen the use of DSDM.
There were two major revisions of DSDM in 2007 and 2014 to combine the existing project
management best practices with Agile development best practices, and it was renamed to the
‘DSDM Agile Project Framework.' Effectively becoming a best practice project management
wrapper around Scrum, and specifically designed to fit corporate environments and
governance without compromising Agile principles.
The diagram below shows the phases of the DSDM Agile Project Framework:
DSDM is based on a fundamental principle that scope, time, cost and quality cannot all be
fixed, and of these, on time, on budget and high-quality are the most important aspects of
successful projects, so scope needs to be allowed to vary. This is very much in line
withAgilepractice which typically controls the same aspects hence it's a natural pairing with
Scrum, where Scrum is used for the Engineering activities, wrapped by the other DSDM
phases that provide the other activities, reporting, governance, etc. required for project
environments.
So despite being used successfully in many organizations, DSDM is not well known because
it has not had the same evangelizing and self-promotion activities over the years compared to
several of the other well-known methods. Additionally, it’s been designed for internal use, i.e.
for running projects within an organization and not where there’s a customer/supplier
relationship and contracts between the customer and delivery teams. So some adaptations
are required in commercial environments. It is also not designed for fixed-scope type projects,
and again needs to be adapted in these cases.
In the right context, the Waterfall method can be used successfully. In environments where all
detailed requirements are known with high certainty up-front, where there is very little change
or business uncertainty and where there is little technical risk. However, even in these
environments, considerable risks remain by leaving testing and customer visibility until the
very end when it’s too late to change anything of significance, and the longer the project
duration the greater these risks become.
RUP can also be successful where customer and project teams have in-depth knowledge of
the method and are skilled at tailoring it to their needs. However this is difficult to get right, so
teams often leave unneeded work in the project, leading to additional cost and time.
Agile methods such as Scrum are great for the development of software in environments
where there are highly collaborative relationships between the business owner and project
teams, however, these methods have very little regard for the types of activities that typically
occur at the start and end of projects. Although in recent years, methods like DSDM have
evolved to tackle these shortcomings with the development of Agile project management
frameworks and wrappers around the process and practices used by Scrum and XP.
There is no one-size-fits-all method for successful software development. With all methods,
there are successes and failures, regardless of whether using Waterfall, RUP, Agile or less
well-known methods like DSDM. The ‘right’ approach is to select the appropriate method for a
given project context, and sometimes by taking a blend of different methods. The key is being
appropriately skilled and experienced to understand the different options and how best to
apply them.
Implementation Projects
When ASAP 8 was released in 2012 and supported the implementation of SAP Business
Suite including Analytics, Business Warehouse, and other predominantly on-premise
solutions. This version of ASAP was built to support SAP’s transition to using the assemble-
to-order approach in services and project delivery.
Standard ASAP
Assemble to Order (A2O) ASAP
Simplified Rapid Deployment Solution (RDS) ASAP
Agile ASAP
Recently SAP added cloud-based solutions to its portfolio including solutions such as
ByDesign, Cloud for Customer (C4C) and Ariba. These cloud-based solutions required a
different implementation approach, so SAP developed a new additional methodology
specifically for these solutions called SAP Launch – built on existing methodologies
developed for SuccessFactors, ByDesign, and Ariba.
As SAP acquired new companies, its product portfolio further expanded with new products
with different technologies and their specific implementation approaches, methodologies and
deployment models; some cloud-based, some on-premise. SAP also added mobile solutions
to its portfolio, again with different implementation and deployment models.
SAP quickly recognized that all these different approaches and standards were adding
complexity, with a lack of alignment in terms of language, naming, deliverables, tasks,
artifacts, etc. which if left alone would create confusion and inefficiency internally and for
customers and partners. So in 2015 SAP created SAP Activate.
SAP Best Practices – business and technology processes optimized for the relevant SAP
products
Guided configuration – content lifecycle management tools to configure and test the selected
SAP Best Practice processes, enabled for business users without IT involvement.
SAP Activate methodology - new implementation methodology that builds on proven
approaches and SAP’s experience to offer a consistent, Agile-style approach for any
deployment type – cloud, on-premise, hybrid, or mobile.
The methodology contains the best practices from ASAP and SAP Launch to create a
harmonized methodology and practices for all SAP solutions while allowing for product
specifics and variations within different variants. SAP Activate will replace and succeed
ASAP, SAP Launch and other product-specific methodologies.
The SAP Activate methodology is developed to take a whole-lifecycle approach, similar to the
SAP Hybris Application Lifecycle Framework (ALF) for Commerce. So in addition to the initial
implementation project, it is also focused on operations and future innovations. As such a key
goal of SAP Activate is to use best practices to reduce customizations away from the
standard product, which in turn reduces effort and cost, and subsequently allows customers
to take advantage of faster deployments of innovations released in new product releases.
SAP Activate recognizes there are distinct differences between cloud-based and on-premise
implementations, and also hybrid approaches, so there are different SAP Activate variants
that specifically cater for these different types of deployment models, and also product-
specific variants where appropriate.
However, all variants will share the same overall structure, phases and objectives and all
focus on the same key characteristics:
1. Start with ‘best practices’ (knowledge assets and pre-built content) that serve as starting point
for initial fit-gap analysis workshops, to ensure implementations are in line with product best
practices and not excessively customized.
2. Use Agile practices during the implementation to validate the solution with end-users as
quickly as possible and ensure fast feedback cycles.
3. Ensure quality is built-in from the start, with a structured quality management plan, quality-
gate checks, and appropriate forms of testing throughout the project including acceptance
testing.
SAP Hybris Commerce is a platform with various modules that customers can select
depending on their needs. The customer’s Hybris Commerce solution is built on top of this
platform by the development of software that extends or overrides the default behavior, and to
implement new features and functions.
Because the solution is built around software development, Hybris Commerce implementation
projects are managed as software development projects, and as such can be managed using
a variety of different software development lifecycle (SDLC) methods depending on the
particular project context, from Waterfall to Rational Unified Process (RUP) to Agile. There is
no single ‘right’ approach; it depends on the customer, the ways-of-working, the delivery
team’s skills and experience, the governance processes, the amount of uncertainty, the rate
of change, etc. Therefore Hybris Commerce customers and implementation partners
use a wide variety of methods and hybrid approaches.
Over the past years utilizing their experience of a wide variety of different projects, the Hybris
Expert Services teams developed an implementation framework called the Project Delivery
Framework that was designed as a high-level reference framework specifically for SAP
Hybris Commerce projects, with sub-frameworks focused on a specific SDLC
approach. The direct delivery teams within the Hybris Expert Services teams specifically
developed a sub-framework called the Agile Project Delivery Framework documented in this
Hybris Application Lifecycle Framework (ALF) for Commerce, with scope for other
frameworks to be created in the future.
This Project Delivery Framework has been developed to be shared with customers, partners
and all internal SAP teams so that it can be used as a reference framework for teams
implementing SAP Hybris Commerce. With SAP Activate being released, it has also been
adapted and realigned to work within the overarching SAP Activate framework while retaining
the specifics required for Hybris Commerce implementations.
The adaptation of SAP Activate for Hybris Commerce implementation continues to evolve.
The team can apply the SAP Activate for Hybris Commerce by referring to phase activities
and key deliverables described in the wiki and the details will be maintained in the Roadmap
Viewer in the future.
This diagram shows the phases and life-cycle behavior of the SAP Activate
methodology that is common to the overarching framework and all variants:
The specific objectives, activities, tasks and deliverables will vary between variants. The
below diagram shows the different phases and primary goal and activities for SAP Activate for
on-premise.
Each of these phases is summarized for quick reference purposes. Please refer to the Jam
site for more details.
Benefits
Guiding Principles
The SAP Activate methodology is built to support customers, SAP and partner teams during
the implementation projects that are delivered individually or as part of an engagement under
the SAP MaxAttention or SAP ActiveEmbedded agreement. The methodology builds on the
following guiding principles
Re-use of knowledge assets and pre-built content like Model Company, RDS or Best
Practices
Leverage the flexibility of the cloud
Agile solution deployment with incremental and iterative build of high-priority capabilities
Co-Innovate with Customer
Implementation and Operations fully supported with Innovation Control
Center/Operations Control Center and Mission Control Center for Premium Engagement
Customers
Target Audience
The methodology is developed primarily for SAP customers, partners and the Service and
Support Teams, specifically the following roles:
Go to start of banner
The goal of the Discover phase is for the customer and project team to explore and agree on
a high-level common understanding of:
Together these will give the customer enough information to decide whether to invest in the
next phase of the project, i.e. the Prepare phase, which will explore these topics in depth. Or
maybe the customer decides to not continue with the project at this stage. It’s much better to
discover this earlier rather than later when significant effort and resources have already been
committed.
Typically, the Discover phase starts with the first discussions between the customer and the
members of the project team and concludes when the Prepare phase begins. It could last
weeks or months, depending on the readiness, the availability and the timeline of both the
customer and the project team. Usually, the Discover phase only occurs once in the lifespan
of a single project when the customer is assessing whether to proceed with the project or not.
Key Activities
Key Deliverables
Strategic Planning
Application Value and Scoping
Trial System Provisioning (optional)
Key Deliverables
Init
Planning
Organizational Change Management (OCM)
Enablement Charter (optional)
Team Enablement
Activate Solution (optional)
Project Delivery Platform Setup
Run Prototyping
QG1 - Run Quality Gate Prepare to Explore
Unless otherwise noted, this guide will describe the Explore phase for the first project release.
This will enable the reader to understand the full set of activities. For subsequent Explore
phases, some of these activities may be shortened or omitted as appropriate.
The Explore phase is best delivered as a series of onsite workshops in close
collaboration with the customer, the project team, and other important stakeholders.
As well as being the best format for gaining understanding and discussing the various topics,
these collaborative workshops also enable the various parties to establish personal and
working relationships which are very important for the success of the project.
Key Activities
Prepare, setup and conduct workshops
Identify master data and organizational requirements
Define functional requirements
Define non-functional requirements
Design Architecture & System integrations
Define environments and tooling
Define Quality Management and Testing strategy
Associate business requirements to the process hierarchy
Analyze learning needs and develop a training strategy
Plan and finalize project release schedule and budget
Obtain business sign-off prioritized backlog and design documents
Key Deliverables
Organization Change Management
Planning
Enablement Analysis
Data Migration Design
Technical Architecture Definition
Technical Design (optional)
Fit-Gap
Design
Design Review
Story Prioritization
Verify and Accept
Data Volume Planning (optional)
Data Volume Design
Custom Code Impact Analysis (optional)
Sizing (optional)
IT Infrastructure Definition
Operation Impact Evaluation
Security Design
Dev Setup
Project Delivery Platform Setup (optional)
Q2 - Run Quality Gate Explore-to-Realize
SAP Activate - Realize
The primary objective of the Realize phase is to
iteratively analyze/design/build/test the software
to meet the functional and non-functional
requirements of the current release as defined
during the preceding Explore phase.
Essentially the Realize phase is based on Scrum, the most commonly known Agile method
(https://en.wikipedia.org/wiki/Scrum_(software_development)).
However whereas textbook Scrum is designed for continuous software development internally
within a single organization, here it’s used within the context of a release which in turn is
within the context of a project, often where the project team and customer belong to different
organizations and the project is being delivered on a contractual basis. Therefore the textbook
Scrum approach has been adapted within this phase to cater for these additional factors.
Note that in Scrum iterations are called ‘sprints’. These terms can be used interchangeably
during the Realize phase as they have the same meaning, however, it’s recommended to use
sprint because that communicates to everyone that the teams are using a Scrum-based
approach.
1. Set-up sprint (commonly called sprint zero) – preparation for the subsequent
implementation sprints, e.g. set-up tooling, environments, and test data.
2. Implementation sprints (multiple) – fixed duration software development iterations, i.e.
analyze/design/build/test.
3. Hardening sprint – finalization of the software produced in the previous implementation sprints
in preparation for UAT.
4. User acceptance testing (UAT) – formal customer acceptance testing of the software.
Typically there are also a number of parallel activities that are often planned as part of this
phase, although often they are managed as a separate cutover activity, for example, end-user
training. However, they are all dependent on the software (and therefore deliverables) of this
Realize phase so need to be planned together.
Key Activities
Setup sprint that covers infrastructure, development and tool-setup activities, knowledge
sharing and first sprint preparation
Establish the solution landscape
Implementation sprints where analysis / design / build / test activities are performed in time-
boxed iterations
Conduct overall end-to-end testing of the solution within the QA environment
Setup production environment
Prepare for data migration and data archiving
Conduct system integration testing
Conduct performance testing
Conduct security testing
Hardening sprint activities as the last sprint of Realize phase
Conduct project team and key user training
Finalize end user training materials and documentation
Support User Acceptance Testing
Key Deliverables
Execution, Management, and Controlling
Organizational Change Management
Enablement Realization (Optional)
Configuration - Introduction
Test Execution
Project Delivery Platform Setup
Dev Setup
QAS Setup
Cutover Preparation
Data Migration & Verification (Optional)
Test Preparation
Custom Code Management Execution (Optional)
Product Enhancement (Optional)
Security Implementation
Sizing, Scalability Verification (Optional)
Operation Implementation (Optional)
Business Process #1-n - Detailed Design (Iterative)
Business Scenario #1-n - Detailed Design (Iterative)
Technical Solution Design (Iterative)
IT Infrastructure Setup and Test (Optional)
QG4 - Run Quality Gate Realize to Deploy
Therefore although not mandatory, it’s highly recommended the software developed
during every release is deployed to the live production environment accessible to real
end-users during a deploy phase at the end of each release. This will allow the customer
and project team to:
1. Verify functionality, assess real business value, and gather feedback from end-users as
soon as possible so changes can be fed into the planning for the next release. This feedback
will allow the customer to adjust the prioritization of new features according to real feedback,
rather than based on assumptions about what end-users want.
2. Verify non-functional aspects of the software by proving the solution in a real production
environment, e.g. the solution scales as expected, performance meets requirements, caching
strategies work as expected, etc. Testing can only verify so much. Only a real-live production
environment with real end-users will properly verify that the non-functional requirements are
met. Feedback here will also allow for better prioritization in the next release, e.g. the
technical value of a new caching strategy to improve performance might be increased which
makes it higher priority compared with some less valuable functional requirements.
3. Avoid the much riskier “big-bang” approach where software is developed over several
releases but only deployed to live environment after several releases. With big-bang releases,
any issues will be found too late to change, which will have a major impact on users and the
long-term success of the project, e.g. architectural issues are very costly to change later.
The purpose of the Deploy phase is to support this deployment into the live production
environment and to provide the customer with dedicated post-live support immediately
following the go-live.
Key Activities
Key Deliverables
Closing
Hyper Care Support (Optional)
Handover to Supper Organization (Optional)
QG5 - Transition to Support Organization
Therefore we have created the Agile Project Delivery Framework (Agile PDF)
specifically to deliver Hybris Commerce projects using Agile practices and processes,
to take full advantage of the key advantages of Agile and focused to:
Embrace change
Reduce time-to-market
Focus on highest value first
Ensure high customer visibility & collaboration
Ensure high quality
With an Agile approach we recognized that Scrum and XP technical practices were the best
approaches for developing the software itself, however, they have no concept of project
practices. So we wrapped them in the Agile Project Management Framework provided
by DSDM (https://en.wikipedia.org/wiki/Dynamic_systems_development_method) then
applied the sequential phase practices from Rational Unified Process (RUP) together with
learnings and continuous improvement from our own experiences working directly on many
Hybris Commerce projects.
Fundamentals
Extensive analysis and research conducted by DSDM over 20 years of studying projects
found a project's success is based on whether it was on time and on budget and delivered
high value, not whether every feature regardless of value was delivered. This is the basic
fundamental principle of DSDM, and also forms the basic fundamental principle of the Agile
Project Delivery Framework.
Most people are familiar with the project management iron-triangle concept that attempts to
fix features, time and cost, and assumes high quality. However, it's well documented that
wherever there is complexity (inherent in software development projects), one or more of
those aspects need to flex. Based on DSDM's basic fundamental, and the supporting Agile
principles, the Agile PDF controls time, cost and quality, but allows features (i.e. scope) to
flex.
Variable scope means that features can easily be swapped in or out, and focus will be on
delivering those highest value features first, leaving the lowest value features to later.
However, it also means that contingency is planned around features, not time or cost so that if
the unexpected does occur, some of the less valuable features can be deferred whilst
ensuring the project is delivered on time and on-budget and is still considered successful.
Assumptions
The Agile Project Delivery Framework is variable-scope by design. Therefore it is not directly
applicable for fixed-scope projects. Although many of the practices and concepts can be used
in a fixed-scope project, there will be fundamental differences, especially in terms of scope
and requirements management and change control.
It is designed and explained from the perspective of the organization providing the
implementation services for a customer organization that has a SAP Hybris Commerce
license. However, many of the practices and concepts will be equally applicable to an internal
IT department delivering the solution within their own organization, in which case the
customer is an internal customer.
The intention of this framework is to keep as close to the Agile fundamentals and
principals as possible, therefore it’s also designed for:
For projects where some of these assumptions are not applicable, the Agile Project Delivery
Framework might still be used successfully, however, trade-offs will need to be properly
considered and balanced.
Phases
Phases Summary
Initiation The Initiation phase is the first part of the discovery and planning activity of a
new project. Its primary objective is high-level alignment between the
customer and the project team on the why/what/how/when/cost/risks of the
project. This is essentially a feasibility/pre-sales activity before any significant
implementation effort is spent on the project.
Foundation The primary objective of the Foundation phase is to establish foundations for
the project from business, technical and project management perspectives.
This involves establishing an understanding of the business requirements for
the project, agreeing on the approach, and determining how development and
Phases Summary
Exploration This is an optional phase within the Agile Project Delivery Framework. Its
purpose is to allow teams to explore areas of significant risk or uncertainty
that still exists after the Foundation Phase, and are preventing the customer
from making the decision whether or not to proceed with the Engineering
Phase, and maybe even the project as a whole. Typically these are areas of
technical risk.
Deployment The primary objective of the Deployment Phase is the successful deployment
of the solution delivered by the preceding Engineering Phase into a
production environment so it’s accessible to end users. This phase includes
the provision of immediate post-live support to ensure stability and fast
resolution times in case of any issues.
Below is an example project plan for an Agile PDF initial implementation project:
The duration of the phases can vary however this is a very typical plan.
The Initiation phase isn't shown as typically this is either an in-house feasibility study or pre-
sales phase for an external services provider, so at this point, the project hasn't formally
started. One of the objectives of the Initiation phase is to create this initial high-level project
plan.
The first Foundation phase is usually longer than subsequent Foundation phases as a lot of
the output remains valid for the next Foundation phase. Subsequent Foundation phases
mainly focus on reviewing the existing and known items in the backlog, plus any new items
that have been identified since the previous Foundation phase.
The Exploration phase is optional in case of high uncertainty or technical risk after the
Foundation phase, e.g. requires a proof-of-concept. If this phase is needed, typically it only
occurs once in the lifecycle of a project and it’s relatively short in duration.
User Acceptance Testing (UAT) is during the Engineering phase, typically as a block of
activities at the end of the phase, although in some cases it can start earlier.
The Deployment phase often overlaps the end of UAT as production readiness activities can
start before acceptance testing is finished.
Go-live is at the end of UAT and usually towards the start of the Deployment phase, with the
bulk of the Deployment phase activity being immediate post-live support. This is not the same
as regular support provided by Application Management as post-live support usually delivered
by the Engineering team in conjunction with Application Management during this critical post-
live time period.
Subsequent Foundation phases can run in parallel to the Deployment phase for the previous
release, but only where there is no risk of distraction. Foundation phases require dedicated
focus from the key customer and implementation team members, and if there are production
issues these people are likely to be pulled out of the workshops, therefore increasing the risk
of the next release because not enough effort is spent during the Foundation phase.
Application Management often starts ramping up and preparing during the preceding
Engineering phase, e.g. support engineers working as part of the development team to gain
knowledge and experience.
1. Eliminate waste – always look to identify where effort is being wasted and work to eliminate it,
therefore maximizing efficiency
2. Build in quality – quality must be baked-in from day one, fixing defects is expensive and
wastes energy
3. Amplify learning – teams must be allowed to learn and create knowledge to strive for
improvement continuously
4. Defer commitment – avoid making decisions until they are needed, changes are expensive,
and effort is wasted spending time on something before it’s needed
5. Deliver quickly – limit the size of the work to smaller pieces so that they can be delivered
more often and more quickly. Working on small pieces is far more efficient than working on
large pieces that are delivered less often. It gets teams into regular patterns and rhythms, so
they become more efficient
6. Empower the team – people need to be respected and empowered to make decisions to
improve the way they are working.People work differently so let them find the best way to
work together by setting shared goals and commitments and support them finding the best
way to achieve these goals
7. Optimize the whole – always look at the big picture, how systems, processes, and people
interrelate and look at the overall goals
When people talk about Agile they often talk about Scrum, however, it’s important to realize
that Scrum itself is based on a core set of values and principles defined as the Agile
Manifesto (http://www.agilemanifesto.org).
It’s important to note that for each of the above, Agile doesn’t say we shouldn’t do the items
on the right; it says “while there is value in the items on the right, we value the items on the
left more.” Unfortunately some teams “doing Agile” take this too literally and don’t do enough
of the items on the right, and it’s this that is the main cause of failed Agile projects. In fact,
when done properly there is still a lot of focus on those items on the right, it’s just not the main
focus.
Based on these values the Agile Manifesto states the following principles:
1. Our highest priority is to satisfy the customer through an early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is through a face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity, the art of maximizing the amount of work not done, is essential, e.g. “keep it
simple, stupid” (KISS) and avoid over-engineering (gold-plating)
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Agile’s values and principles work because of the science behind Lean, and they are closely
related. So it’s important to understand and appreciate them both together. An easy way to
think about the Agile Project Delivery Framework is that it’s based on Agile, and Agile, in turn,
is based on Lean.
Now that we understand the underpinning Lean and Agile principles, we'll take a look at the
principles and practices that are essential to the success of an Agile PDF project.
These are:
1. Variable scope
2. Time-boxing
3. Iterative development (sprints)
4. Just-in-time requirements analysis
5. Iterative documentation
6. Acceptance criteria
7. Lightweight change control
8. Quality baked-in
9. Empowered customer representatives
10. Cross-functional collaboration
11. Continuous improvement
12. Creative design
13. Transparent reporting
14. Contracting model (if appropriate)
Most people are familiar with the classic project management iron-triangle that tries to fix
features (scope), time and cost, and assumes quality will remain high. It's well documented
that wherever there is additional complexity, one or more of those aspects need to be flexible.
Based on DSDM's basic fundamental, and based on the supporting Agile principles, Agile
PDF controls time, cost and quality, but allows features to be flexible.
This means that features can easily be swapped in or out, and focus will be on delivering
those highest value features first, leaving the lowest value features to later. It also means that
contingency is planned around features, not the time or cost so that if the unexpected occurs
some low-value features can be deferred to the next release while ensuring the current
release is delivered on time and on budget with high-quality.
This is achieved by dividing the feature scope into must-haves and should-haves, where
must-haves are requirements that will stop a go-live if not delivered and should-haves are
requirements that might cause challenges if missing, but won’t be severe enough to stop the
whole go-live. If all goes well and the team has fully understood the requirements and risks,
and all assumptions are correct and nothing unexpected happens, all planned must-haves
and should-haves will be delivered. But if something doesn't go quite to plan, then we keep to
the same time and cost, but some of the low-value should-have features will be deferred to
the next release.
With this approach, it’s recommended that the up-front scope agreed with the customer for an
initial release be split 60/40 with 60% must-have requirements and 40% should-have
requirements. This 40% should provide adequate contingency needed to ensure the project is
delivered on time and on budget, although, in theory, the team may be able to deliver 100%
(or more). It should also ensure the release can still go-live because it would take something
very fundamentally wrong to cause the scope to be reduced by greater than 40% to force
deferring must-haves.
It’s important to maintain this 60/40 and to resist the natural pressure from the customer to
increase the must-have %. Otherwise, the project risks are increased significantly before the
project is even started. This is because once the should-have scope contingency is
exhausted there is no planned contingency remaining, so inevitably time/cost needs to
increase to manage any further late dependencies, unforeseen complexities, unplanned
inefficiencies, or other unexpected events. Once time/cost starts increasing, and de-scoping
has already been done, there will be a perception that the project is failing which will put
significant pressure and stress on the project team, which in turn will impact quality, which will
likely have major long-term consequences for all parties.
Aside from contingency, the more positive aspect of variable scope is the flexibility to easily
swap scope without a formal change control process. Within a release, it’s relatively
straightforward for a customer to request scope swaps. The only caveats are:
(1) The scope being removed must be of equal size to the scope being added, so the overall
total remains the same
(3) Scope already agreed upon for an active sprint can't be changed at the customer request,
only the project team can request a change to this scope because scope changes mid-sprint
are very disruptive and cause significant waste. An example of a typical reason for mid-sprint
scope changes are newly identified dependency issues which are blocking
development/testing. In this case, it's best to move that scope out and replace it with
something that can be delivered.
Time-Boxing
Within an Agile PDF project, everything is time-boxed, so it has a fixed start and end time.
This includes releases, phases, sprints and even meetings. This time-boxing ensures time
control is baked into everyone’s mindset from day one, and it’s important that nothing is
allowed to extend outside its time frame. Ultimately, this naturally ensures all the project
activities are delivered on-time, and therefore increases the likelihood of a successful project.
By time-boxing regular events, people get used to the rhythm. It helps them to optimize their
time to suit the project needs thus leading to a more focused use of time and less wasted
time.
Iterative Development (Sprints)
The Engineering phase consists of iterations called sprints. This is a Scrum term meaning
mini analysis/design/build/test activity cycles typically fixed at 2-3 week durations. The
duration is set at the start of the project and is then fixed/time-boxed for every sprint and only
changed in very exceptional cases. Changing the duration mid-project is very disruptive as it
will have a knock-on effect for subsequent activities on the critical path, and therefore the
project/release end-date. It will also impact the established rhythm of the team introducing
wasted effort and making them less efficient.
Although each sprint consists of analysis/design/build/test activities, typically these are not
performed in sequential blocks which are typically inefficient and wasteful (also referred to as
“mini-waterfalls”). Instead, there are multiple parallel analysis/design/build/test activities
happening for each requirement. By empowering the team, have them commit to a sprint
goal, then allow them to self-organize to meet that goal while providing guidance and
proactively removing impediments, allows them to organize these activities to maximize
efficiency. This is a typical Scrum activity.
As well as being the most efficient way to develop software, breaking the development into
fixed duration sprints allows a continuous and regular delivery of working software enabling
the customer to test early and for end-users to provide early feedback. Not only does this help
improve quality by identifying defects early rather than waiting until the end of the release, but
it also allows for the customer to change their mind about requirements or priorities for
subsequent sprints once they start seeing the solution in action.
These regular deliveries build trust and early buy-in between the project team and the
customer. It’s amazing the difference it makes to the working relationship when they see such
a quick turnaround.
Just-in-Time Requirements Analysis
Customers typically have a wish-list of requirements at the start of a project, however, often,
they don’t really know what they want in detail. Even customers that are re-platforming and
say they know exactly what they want because they already have it often change their minds
once they start understanding the Hybris Commerce platform and its out-of-the-box features,
or their competitors have released something new or end users starting using the solution as
it’s delivered with each sprint.
It’s important that requirements are only estimated at a high level early in the project, then
elaborated and defined in more granularity only when needed as the project progresses.
Because change is inevitable, it’s wasted effort to analyze everything in detail up-front.
For example, very high-level features are identified and estimated during the Initiation phase
to provide enough understanding to give an initial high-level estimate to size the whole
project. During the Foundation phase, these are re-evaluated and prioritized into a series of
releases. Only the requirements for the first release are broken down further to provide just
enough detail to enable reliable planning for that release, leaving all the other high-level
requirements for a subsequent Foundation phase. Then before each Engineering phase
sprint, only the requirements to be developed during that sprint are broken down to the most
granular level ready for sprint planning and subsequent development and testing.
Using this approach ensures that a huge amount of wasted effort is avoided compared with
analyzing all requirements up-front as dictated by the Waterfall model. It also allows
development to get started earlier, and thus start delivering more quickly. Teams don’t have
to wait until all future requirements are analyzed before starting on the highest priority
requirements. It avoids waste because inevitably some of those later requirements will
change, so the analysis will need to be re-done.
Iterative Documentation
Just because an Agile approach is being used, it doesn’t mean that there are no functional
requirements or technical design specifications and no sign-off process. Rather than being
completed up-front then updated throughout the project with change requests, they are
completed iteratively using a just-in-time approach during the project.
The equivalent to the functional requirements specification is created as the project team
progresses through the requirements sprint-by-sprint, as they define the acceptance criteria
for those requirements for each sprint. These acceptance criteria are the detailed functional
requirements and are signed-off before development starts. Therefore by the end of the last
sprint, there is a complete list of all functional requirements delivered during that release and
their detailed acceptance criteria. The result is the same; it’s just completed in a much more
efficient manner.
Similarly, the equivalent of the technical design specifications is also created iteratively during
each sprint as the requirements are developed. This way designs are documented only once
they are known, and not up-front where there is a high level of uncertainty about how
everything will be designed in detail. Again the result is the same but completed much more
efficiently.
Often when done up-front, requirements and technical design specifications are out-of-date
and inaccurate by the end of the project. People don’t take the time to keep them properly
updated with the inevitable change requests, so they become a major source of wasted effort.
By creating them iteratively and just-in-time this problem is also avoided.
Acceptance Criteria
Acceptance criteria are specified for both functional and non-functional requirements. These
are agreed and signed off by the customer. The functional acceptance criteria are defined and
signed off sprint-by-sprint, the non-functional acceptance criteria are defined and signed off
during the Foundation Phase, then amended via change control during the Engineering phase
if needed.
Test automation is then created around these criteria as the sprints progress. The functional
tests are done sprint-to-sprint as they are developed, and non-functional tests as appropriate.
Having a high level of automated coverage allows the testing teams to focus only on new
requirements in each sprint and not spend wasted time with continuous manual regression
testing, as the automation tests should pick up regression issues. Thorough test automation
also gives a very high level of confidence when entering user acceptance testing at the end of
the Engineering phase.
These acceptance criteria are then used as the basis for the customer’s user acceptance
testing. This is made easy for them as the completed requirements and their acceptance
criteria are delivered at the end of each sprint, making the creation of test cases much simpler
compared to someone trying to create them from scratch using a huge functional
requirements specification document as a starting point. The acceptance criteria are already
written in a format that makes creating test cases relatively straightforward.
Lightweight Change Control
Using an Agile approach that allows for flexible requirements during an on-going project
enables change to be embraced rather than resisted. Therefore a lightweight change control
process is allowable rather than the typical rigorous change control process seen with fixed-
scope projects. Scope changes can be verbally agreed with the project team, usually with the
Project Manager. There is no need for formal documents or contractual changes every time
requirements change.
The only time a formal change request is required is if there’s a material change to any
contractual terms, i.e. changes to deliverables, cost, time or services. These typically only
occur when the customer wants to extend the release, for example by adding another sprint.
A benefit of requiring a formal change request to extend the time is it acts a barrier for the
project to be extended. Therefore this natural resistance is more likely to keep the project on
time and on budget unless there are exceptional reasons and the customer wants to go
through the effort of making this formal change request.
Quality Baked-In
Quality is hugely important to any Agile PDF project and must be baked in from day one. The
testing team needs to be involved with the development team from the start of the initial
Foundation phase. They need to be involved in all estimations and drive the agreement of the
project testing strategy with the customer during the Foundation Phase.
All testing activities must be identified from the start, responsibilities assigned, and planned
alongside all other critical path activities. These will cover all aspects of testing including
functional, non-functional, exploratory, system integration, cross-browser, and cross-device
testing.
Testing should never only be left to the customer, and should never only be left to the
developers. Dedicated and professional testers are an essential part of the project team and
need to work alongside the developers, ensuring quality throughout every stage of the project
lifecycle. All deliveries to the customer must be properly tested beforehand to minimize
defects and wasted cycles investigating/fixing defects and re-delivering for repeated customer
testing, all of which is a huge source of wasted time and effort.
Investing in dedicated testers within the project team will easily pay off over the course of the
project, and it’s vital they are planned from the start. They are a key part of the project team.
Empowered Customer Representatives
Fast, effective and efficient collaboration and decision-making are essential to the success of
the project. Because requirements are elaborated just-in-time, there is a high level of
communication required at all stages of the project. This is a big change from Waterfall
projects, where the customer is typically only heavily involved during the initial analysis
phase, then again in the testing phase at the end of the project.
The customer team must be empowered to make decisions, and single representatives must
be identified to manage this from business, technical, project management, and quality
management perspectives. There might be multiple people behind them, but one person must
be accountable for ensuring questions are answered and making decisions even if there are
multiple different views internally.
If the customer is unable to provide these dedicated representatives and they are not properly
empowered, decisions will not be made in a timely manner which will create delays and
frustration on all sides, and ultimately significantly reduce the efficiency and productivity of the
project team.
Cross-Functional Collaboration
Agile PDF encourages cross-functional collaboration through four streams: project
management, business, technical and quality management. Each of these streams has a
corresponding owner on the project team and the customer side. This improves
communication with the customer and underlines the importance of each of these
perspectives.
Continuous Improvement
Continuous improvement isn’t specific to the Agile PDF. However, it’s a cornerstone of the
efficient and effective workings of the project team. There are regular meetings (called
retrospectives) to discuss what was good, bad and can be improved at specific points in the
project. Actions are taken for the most valuable areas of improvement; they are implemented
and monitored, then reviewed again to check they were effective. Then the next most
valuable areas are tackled, and so on.
Retrospectives are a vital part of the workings of the Agile PDF project and occur at the end
of every sprint, release, and project. This process of continuous improvement becomes
embedded in the mindsets of the whole project team, which not only improves ways of
working but is also very motivational as it empowers the team to make positive change.
Creative Design
Often there is a separate organization or design team responsible for designing and creating
the user experience and creative designs for the user interfaces. The project team is
responsible for taking these designs and integrating them with the back-end development to
meet the overall requirements.
In these cases, it’s essential the three key parties (customer, design team and project team)
collaborate from the start and throughout the project. There are tight dependencies between
the designs and the implementation, along with trade-offs regarding features and effort.
Creative designs are created at the start of each release and before the start of the first
Engineering phase where they are required.
Typically used where there is only limited collaboration between the parties to ensure the
project team can proceed without constant delays due to missing creative design
dependencies.
However, if designs are completed and signed off before the project team is involved it
becomes very difficult to change the designs as the design team may no longer be involved in
the project, and the design budget might be fully exhausted. This creates a significant barrier
to change during the project that essentially leads towards fixed functional requirements and
counter to the variable scope expected by all parties.
Creative designs are created just before they are needed by the project team. Often in
practice, this means designs are completed one sprint ahead of when they are required.
However, if designs are not completed early enough, this could have a significant impact on
progress due to emerging requirements and the impact these may have on other areas of the
solution.
Unexpected requirement changes caused by changes to the designs can be handled through
scope swapping if required.
Regardless of the approach, the way of working between these three parties needs to be
agreed upon from the start of the project, and constant focus and continuous improvement
maintained throughout the project.
Transparent Reporting
One of the main advantages of Agile PDF is that it provides highly visible and transparent
progress reporting. Working software is delivered to the customer with each sprint, and real-
time progress is made visible using burndown charts (a Scrum concept) during each sprint so
the project team and stakeholders can see if the sprint target is going to be achieved. There
are also release burndown charts to show whether the release as a whole is on track (i.e.
across all the sprints in the release). If it looks likes targets are not going to be met, early
action can be taken.
It’s essential that these real-time progress reports be shared with the customer, and that the
customer is educated so they can fully understand them. This builds trust from the start and
avoids surprises later. If something is going off track early, it’s far better to tackle this together
with the customer at the first signs, than hiding and hoping it improves. Trust is an essential
part of the collaborative working and therefore the success of the project. As soon as the
customer thinks something is being hidden that trust is damaged and it’s very hard to repair it.
Far better to talk about issues up-front and tackle them together in partnership while working
towards the shared goals and objectives of the project.
Contracting Model (if appropriate)
Because scope is allowed to vary, it cannot be fixed up-front. If using Agile, it’s very difficult to
use a traditional fixed price contract model that attempts to fix scope, time and cost. This
takes the project towards the Waterfall model and away from the underpinning Agile
principles, which will undermine the success of the whole project if using the Agile PDF
approach.
If a customer insists on fixed price, then much more attention needs to be focused on those
fixed scope requirements at the start of the project to mitigate risk. They must be documented
in much more depth with a formalized sign-off and rigorous change control process to
manage the inevitable changes. Delivering a project this way requires a Waterfall style
delivery model, and this is naturally much more resistant to change, in which case the Agile
PDF approach is not suitable.
There are variations on the traditional fixed price contract model that attempt to cater for Agile
(e.g. value-based contracts). However, these can easily become complex in other ways. It’s
recommended to keep it simple and use a time-and-materials (T&M) contract model. Using a
capped T&M approach with contracted deliverables and milestones and where the cost will
not be exceeded without a formal change request allows both time and cost to be controlled is
another option which gives more confidence to the customer and keeps teams focused on
these two critical components.
Of course, a T&M approach requires greater trust, and this is supported by transparent
progress reporting and regular deliveries at the end of each sprint so the customer can very
quickly see value being produced.
It’s common for customers to initially be skeptical and distrusting (especially if they’ve had
bad experiences in the past). However, it’s always great to see how customers react when
they get working software to play with at the end of each sprint. Typically business users are
amazed (usually expecting only to see something many months later), especially when they
ask for a change and the project team agrees, prioritizes and swaps something else out of the
release scope, all without any expensive change requests. Now they see the value of Agile.
The key is to regularly deliver high-quality working software.
Trust is needed both ways because the project team also needs to trust the customer to work
in a collaborative manner with empowered representatives, and trust they will validate and
test the sprint deliveries throughout the project. If the customer cannot provide these things,
issues quickly appear which make it much harder for the project team to deliver. So a
partnership is required between both parties.
The customer’s perceived risk with a T&M model can also be mitigated by breaking the
project up into smaller pieces and only contracting for each piece in turn. Therefore each
project phase can be covered by a separate contract. This allows customers to only commit to
smaller chunks up-front and also allows the project to be adapted as it progresses, providing
the customer with flexibility. This is all done within an overall high-level project plan and
budget defined at the start of the project. This is in line with Agile’s fail-fast principle so that
the risk to the customer is minimized. If they see the project going off-track early, they can
stop it easily.
For example, the high-level plan above shows two releases, 4 phases in the first release, and
3 phases in the second. In total, there are 7 phases, so this could be divided into 7 separate
contracts if required. The customer only needs to commit to the next contract as the phase
approaches. Of course, they can also commit to more if they want.
Agile PDF - Fundamentals Requirements Management
Two types of requirements need to be managed
throughout any Hybris Commerce project. The
Functional Requirements (FRs), which define the
behavior provided by the solution and the Non-
Functional Requirements (NFRs) which define the
operations of the solution. These are equally
important. It’s useless having the most feature
rich solution if it doesn’t scale and no one can use
it.
Functional Requirements
Functional Requirements in the Agile Project Delivery Framework (Agile PDF) are defined
just-in-time, rather than defining all requirements in detail up-front. The reasons are:
Wasted effort is reduced because time isn’t spent early-on defining low-level requirements for
everything needed in the future, which will inevitably change beforehand and need reworking.
Delivery time is maximized for high-value requirements because instead of spending lots time
up-front analyzing all requirements, only those that are needed next are analyzed, therefore
shortening the overall time before development starts on those high-value requirements.
During each sprint, the user stories are further decomposed into user story sub-tasks and
technical tasks into technical sub-tasks. These sub-tasks represent activities that will be done
during the sprint and are documented using an issue/project management tracking tool, such
as Jira.
The following example shows a feature decomposed into sub-features then subsequently
user stories, technical tasks then user story sub-tasks and technical sub-tasks:
The key principle is that Functional requirements are only expanded when needed to provide
just enough understanding so the project team can understand the complexity and
dependencies, and can estimate the effort. The approach of deferring the requirements detail
is based on many studies showing that estimates don’t get more accurate after a certain
point. In fact, if requirements are too detailed it takes a lot more effort to estimate because
more information needs to be consumed. This approach balances having enough detail to
create appropriately accurate estimates versus too much detail.
Story Points
Agile methods typically measure effort using a concept called Story Points (SP). Story Points
are a pure measure of relative effort and are highly recommended by Agile PDF instead of
estimating using person-days. The purpose of Story Points is to allow requirements to be
easily comparable without needing to know how many people it will take to deliver them. An
alternative estimation method is Ideal Days, however in Agile PDF we will focus on Story
Points as an example, but it’s not mandatory.
Why use Story Points?
By using Story Points instead of person-days, the estimates are abstracted, which eases
discussion and improves accuracy for the following reasons:
We are better at relative estimation than absolute estimation. I cannot tell you how much an
elephant weighs, but I know it weighs more than a horse and less than a whale.
We work at varying speeds. A piece of work that takes you one day might take me two days.
If we agree that that piece of work is 3 SP, then something I think will take me four days will
be roughly double that 3 SP, and you will think it takes two days but still agree that it is double
the 3 SP work.
We can get caught up in discussions about how quickly things should take. It is easier to
debate whether a user story is a 3 or a 5 SP story than it is to debate whether something
should take 2 or 3 days. A commonly heard objection might be "it can't possibly take three
days to build a foobar!".
It mitigates against expectations of perfect delivery. Things often take longer than we think
they will, and there will be a variance in the time taken to complete tasks. If we communicate
estimates to the customer in Story Points, we avoid setting implicit expectations about the
exact time it will take to complete tasks.
We can convert Story Points to person -days. As the project team completes sprints, historical
velocity can be measured. This is the key to using Story Points as you can then make more
accurate estimates of future output.
Estimation
Story Points are used to estimate features, sub-features, user stories and technical tasks.
Typically when estimating it’s recommended to use the Fibonacci sequence to reflect the
inherent uncertainty in estimating. The rounded Fibonacci sequence (0, 0.5, 1, 2, 3, 5, 8, 13,
20, 40, 100) is commonly used in Agile. It reduces the discussion to "is it an 8 or a 13" instead
of wasting time differentiating between an 8, 9, 10, 11, 12 and 13.
Features are initially estimated at a high-level during the Initiation phase and usually
expressed as a low/medium/high Story Point value rather than more specific absolute
Fibonacci values, to reflect the uncertainty of the estimates. After the Initiation phase, all
estimates are absolute values as requirements should be known with appropriate certainty.
Once you proceed with more precise estimates, during Foundation you can either break
features down into smaller pieces to stay within the Fibonacci range of 0.5-40 Story Points
and avoid using the 100 Story Points cards for items which are more effort than 40, or you
deviate from Fibonacci at larger scales, for example, 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 30, 40, 50,
60. Although this not considered standard Agile practice, this allows teams to provide more
relevant estimates and avoid the situation where teams are forced to make something 100
Story Points when in fact they are closer to 40 Story Points.
During the Foundation phase, the previously estimated features are reviewed and fine tuned
as needed, they usually should not need re-estimating unless something has changed
significantly, for example, if the customer changes the scope or wants to prioritize different
parts of the feature. Once the estimations in Foundation are established for a given release,
they act as a project baseline. This Story Point baseline serves as a total estimate of effort for
the release.
In Engineering, when splitting features into sub-features, the sub-features are estimated, with
the total size equaling the feature size. The same goes for splitting sub-features into user
stories and technical tasks. When user stories and technical tasks are split into sub-tasks,
these sub-tasks are not estimated, as they can easily have 10 or more sub-tasks and splitting
the story points amongst the sub-tasks would be too much administrative overhead and the
risk that the total of all sub-tasks does not equal the parent would be too high.
Velocity
Velocity is the total number of Story Points delivered during a sprint. This is a key metric
because it’s used to predict the number of Story Points a team can deliver over a number of
sprints, for example, the estimated number of Story Points a team can deliver during an
Engineering phase consisting of 5 sprints. This estimated Story Point capacity is then used
during Foundation planning to create the release roadmap where features and sub-features
are planned for each release based on the total of their Story Point estimates.
Therefore it’s important to be able to accurately predict the velocity of a team. If the team has
already delivered previous projects using Story Point estimations you can use the team's
historical velocity and start from there, assuming the Story Points have been benchmarked
between projects (i.e. a 5 Story Point task is equivalent in both projects).
However, for teams who are new or have never estimated in Story Points, you can only
estimate the velocity. For that, you need to calculate the team’s productivity as the starting
point. An individual’s productivity can be calculated through:
Availability
Experience level
Skill-set
There are many resources on the Internet that discuss velocity and how to estimate for new
teams. These are general Agile practices and not specific to Hybris Commerce projects, so
we will not discuss it in detail here.
Once Story Points becomes the currency of the project, the customer will start trading SP for
changes to requirements and other activities during the project, swapping in/out items of
similar size. For example, Feature A (5 SP) is in scope for release 1 but now the customer
wants to exchange it for Feature B (2 SP) and Feature C (3 SP). This is fine as the total
release SP stay the same, and the 60/40 'must-have'/'should-have' ratio also remains the
same after the swap, so if those 5 SP are must-haves then, the new 2 SP and 3 SP features
should also be must-haves (and vice versa).
As another example, instead of swapping Feature A for two other features, the customer
might want to spend some additional effort on knowledge transfer, e.g., to the application
management team who will be supporting the solution after it’s live. The effort for this
knowledge transfer is estimated at 5 SP, so it can also be swapped.
While scope swapping within a release is fine, scope swapping within an active sprint is only
allowed at the request of the project team, not the customer, as scope swapping within a
sprint is highly disruptive (e.g. new requirement analysis, defining implementation approach,
prepare test data, agree on acceptance criteria etc.).Story Points are a much more efficient
way of managing and communicating effort, rather than the more emotive and less
comparative traditional person-days. Ultimately person-days can always be calculated if
necessary, but if done properly most customers quickly adapt and prefer to use Story Points.
Non-Functional Requirements
Non-functional requirements (NFRs) describe the "constraints", "quality attributes", "quality
goals", "quality of service requirements" and "non-behavioral requirements" of a system.
Informally these are often called the "-ilities", and include requirements related to:
Accessibility
Performance
Scalability
Security
Compatibility
Usability
Maintainability
Portability
Unlike functional requirements, these must always be fully elaborated and signed-off up-front
during the Foundation phase together with their acceptance criteria, then only changed if
required during the Engineering phase using a more rigorous change control process. It’s not
easy to swap or change NFRs like with functional requirements. This is because unlike
functional requirements, NFRs need to be fully known up-front before Engineering starts as
they have an immediate and direct impact on the solution architecture and design, which are
very difficult and expensive to change later.
For example, there is a very significant difference between a system that needs to support 10-
page impressions per second (pi/s) vs. 100pi/s. Not only will this impact software architecture,
but also the production infrastructure, which will also have a significant impact on the overall
cost. All of which must be identified and known by the end of the Foundation Phase.
The goal of the Initiation phase is for the customer and project team to explore and agree on
a high-level common understanding of:
Together these will give the customer enough information to decide whether to invest in the
next phase of the project, i.e. the Foundation phase, which will explore these topics in depth.
Or maybe the customer decides to not continue with the project at this stage. It’s much better
to discover this earlier rather than later when significant effort and resources have already
been committed.
Typically, the Initiation phase starts with the first discussions between the customer and
members of the project team and concludes when the Foundation phase begins. It could last
weeks or months, depending on the readiness, the availability and the timeline of both the
customer and the project team. Usually, the Initiation phase only occurs once in the lifespan
of a single project when the customer is assessing whether to proceed with the project.
From the Agile PDF perspective, the key to this phase is introducing the fundamentals and
core practices and establishing whether the customer accepts that the project is driven
primarily to control time, quality and cost, and that scope is variable to allow change and
manage the contingency if needed. If the customer does not accept this approach, then Agile
PDF is probably not the appropriate delivery approach for this project and another approach
will need to be decided.
Typically the Initiation phase consists of the following steps:
Qualification
The purpose of qualification is to determine if the project, the customer, and the project team
are positioned for success.
It’s essential to qualify potential projects/customers as early as possible to ensure there is a fit
on all sides. As a project proceeds through the phases, greater investments are made with
each phase, both in terms of time and resources, and therefore also greater costs. It’s
therefore very important to establish as early as possible whether the project is viable, and
that the relevant parties can work together for the mutual benefit of succeeding in meeting the
project goals.
Often qualification occurs during the software license sales process, for example, during the
customer's vendor selection process. Sometimes it's afterward, for example, the customer
has already selected Hybris Commerce as the software platform, and now they need to
decide how to implement it. Here we are assuming this is a new customer and with their first
implementation project, although many of these topics will be applicable in other cases.
It is important that whoever is responsible for the project delivery is involved in this
qualification, working directly with sales or other involved teams. Often there is a history of
important topics from the early sales process, so it's also essential that sales are involved at
every step, at least until the first Engineering phase kicks off, that is when the customer has
committed to the project.
Naturally, the sales team tends to be more optimistic regarding complexity and delivery,
whereas the project team tends to be more conservative. That's a key reason why the project
team needs to be directly involved in qualification, working closely with the sales team who
may already have set expectations with the customer regarding implementation dates, effort,
duration, and costs. If the project team gets involved too late in the process, it will be much
more challenging to reset any expectations. It's best to be realistic from the start.
The duration of this phase is variable from weeks to months since there is a limited level of
commitment from both parties as a contract has not yet been signed yet and there are many
internal and external factors and dependencies that can impact the process.
Qualification Activities
Often the sales team are the first contact point if it’s a new customer, or maybe someone else
from an account or customer management team if an existing customer.
They will have background information and very high-level information such as timescales,
business goals, rough project size/budget, challenges, etc.
These internal discussions allow very quick assessment whether it’s viable to engage or
whether an alternative option is more suitable.
Customer Alignment
After internal alignment, an initial high-level meeting should be arranged to allow the customer
and the project team to discuss and explore the why/what/how/when of the project.
This allows a quick assessment on both sides whether it’s viable to continue. It also gives the
project team an opportunity to provide feedback to the customer on areas they might need to
think more about before continuing with next steps.
Ballpark Estimate
The customer might want a clearer idea of how much the project will cost as part of the
qualification process and before proceeding further with the Initiation phase.
This will be a very high-level estimate and is usually based on a requirements spreadsheet
provided by the customer, with some quick question-and-answer sessions to clarify
requirements with the customer.
This won’t be exact, but a ‘ball-park’ estimate expressed as a range using low/medium/high
estimates. Assumptions should also be documented together with the estimates.
This step is optional, as it’s challenging to reliably and accurately estimate a project in this
manner due to lack of information, and the range can be very wide, especially with all the
assumptions. It’s usually much more efficient and valuable to use these requirements as the
base for the following Initiation phase workshop after qualification, so the customer can
explain each requirement in more depth and the project team can suggest alternative options
that the customer might not have considered. This usually produces a much more valuable
and accurate estimate.
Qualification Topics
Project Goals
Agile Working
Determine whether the customer is willing and able to work with an Agile approach. The sales
person might have an idea already, based on previous conversations with the customer.
Determine how the customer’s internal decision making works. Are they top-down or do they
empower people? Are they a collaborative and dynamic organization or do all decisions need
to be approved at C-level? Just because a customer says they can work in an Agile manner,
doesn't mean they can.
If the customer is traditionally a waterfall organization they might still be able to work with
Agile, but this needs to be carefully assessed during qualification.
The amount of time expected from empowered customer representatives is significant. Will
the customer be able to provide single individuals responsible for business, technical or
project management decisions? Can they do this in addition to their "regular" job or can they
provide people full-time on the project? Will they be ready to conduct and manage user
testing every sprint?
It's essential the project delivery method is appropriate for how the teams will work together.
Not everyone is able to work with Agile. Going into an Agile project where the customer team
is not able to work in an Agile manner is very risky.
Greenfield vs Re-Platform
B2B/B2C/PCM
Understand the type of project and type of customer, e.g. business-to-business (B2B),
business-to-customer (B2C), product content management (PCM), etc.
If it's a B2B business they will be less demanding in terms of fancy features, but will perhaps
need more hand-holding in terms of eCommerce best practice, so might need more
consulting/coaching. These customers often have less demanding non-functional
requirements as they tend to have fewer users, but greater order sizes.
If it's a B2C business they will probably be more demanding in terms of features, but maybe
too demanding and want to push the boundaries of the Hybris Commerce platform,
sometimes beyond its capabilities. They might also have more demanding non-functional
requirements.
If it's a pure PCM project, then there's unlikely to be much front-end work, and more
system/data integration. PCM projects can also be much more Cockpit-focused (Cockpits are
the Hybris Commerce business user applications), so it's good to know how much
customization is likely in this area as it could become complex if non-standard. There will also
likely be an existing eCommerce solution that could be a competitor to Hybris Commerce. If
so, this could create some concerns in the existing eCommerce team that need to be
managed.
Accelerator
Understand if expectations around ‘Accelerator’ have already been set with the customer. If
it's been described as “an Accelerator project”, this sometimes means the customer expects a
lot of their requirements are already met out-of-the-box with just some minor
development/configuration effort before any proper analysis has been completed.
Check if the customer has any other major projects running concurrently.
If there are two major dependent systems being developed in parallel this can create a lot of
challenges, both from project management and technical perspectives.
From a project management perspective, it will be very important to manage the program
dependencies and risks. E.g. if there's a delay to one project it can have a major impact on
the second.
From a technical perspective, the system interfaces can become a moving target and cause a
significant amount of rework. E.g. if Hybris Commerce is taking a product feed from another
system and the other system is regularly changing the product attributes or structure, this can
have a big impact, not only for the interfaces but also the data model, service layer, and
everything else that sits on top of the data model in Hybris Commerce.
Timescales
Understand when the customer wants to start the project and when they need it to go live,
and what they mean by ‘start’ and ‘live’. Is start the Foundation or Engineering phase start
date? Is live hard or soft launch date (e.g. full production or limited friends and family)? Or
maybe there's a global rollout and associated live dates?
Understand what can potentially impact those dates, and whether they are fixed or likely to
move.
Check if the customer has any other timescales constraints that might impact the project, e.g.
strict production deployment windows. This can have a major impact on project planning.
Timescales are critical when managing capacity, there is no point engaging with a customer if
they need to start before the project team can engage.
Similarly, if the start date is long into the future and the project team is ready now, then the
risk of having a team on the bench needs to be managed.
Also, need to assess whether the dates are realistic.
Project Size/Complexity
Understand who will be responsible for the long-term development, support and operations
after the initial implementation project. This can have a major influence on the project
planning, dependencies, and risks.
If a customer takes long-term responsibility in-house, understand how this might impact the
team structure as these resources will need to be part of the project team. Also, need to
assess whether it's realistic for the customer to take it in-house. E.g. whether they are set-up
organizationally, have the right skills and experience, etc.
If responsibility will be external, need to find out who will be providing these services and
exactly what services have been agreed. If a partner is involved, then need to understand
how this will work, who has accountability, how this works contractually, etc.
If part of the project team’s organization, need to identify other teams involved and ensure
they are involved in the initial planning as a customer will expect a ‘single face’ and may
expect the collaboration to be factored in automatically.
Partners
Understand the customer’s partner situation. If partners have previously been involved but not
anymore, understand their role and why are they not involved now. Or maybe a partner (or
several) are currently involved in which case need to understand their roles, how they work
together and their goals.
If partners have already been involved but not anymore, find out what they've already
delivered. Sometimes this can be leveraged, sometimes it can create additional challenges.
E.g. if they've already completed some development and charged the customer, the customer
may expect this to be reused regardless of quality.
Sometimes the customer has an incumbent partner in other parts of their business, maybe
this partner wants to get involved.
It's critical to understand the dynamics where there are multiple partners involved. The more
partners involved, the more complex the project can become. It’s very important the customer
and partners establish ways of working with aligned goals.
Hosting/Managed Services
Understand who will be providing hosting or managed services, i.e. who is responsible for the
production and other environments. Is this the customer themselves? An external hosting
company?
Don't underestimate the potential impact a poorly managed hosting set-up can have on a
project.
If provided by the customer themselves, this can potentially become expensive for them, have
long lead times and questionable competence of their team and availability.
If provided by an external hosting company, has the customer already selected and
contracted the provider? If not, then this can impact environment preparation lead times and
potentially delay Engineering start dates. If they have, then the environments might already
be scoped and cost, in which case need to check they are correct otherwise it can have a
significant and unexpected impact on costs and lead times.
Regardless of who is providing the hosting/managed services, it's very important to
understand the services included. E.g. does it include deployments? How much access to the
environments will the project team have? These can have a significant impact on productivity
and the services required from the project team and therefore to include in the effort/costs
estimates.
Contracts
It's very important to understand the required contractual base for the project, e.g. fixed price
vs T&M and any other previously agreed terms and conditions.
However fixed-price is very resistant to variable scope and makes these types of Agile
projects much more challenging without major adaptations which inevitably leads to greater
up-front requirements/design as the project team try to understand all risks and requirements
before committing, so they end up more towards waterfall-style projects with sprints. In which
case, Agile PDF is not suitable.
If using Agile PDF it's highly recommended to engage on a T&M basis (capped or otherwise)
with a commitment to control cost and time. This allows a very lightweight change control
process to support changing requirements and much-reduced up-front analysis/design. The
only time a formal change request is required is if a change is made to a contractual
commitment, e.g. services/deliverables/cost/time. Typically this only happens if the customer
wants to extend a phase.
Location
Understand where the customer is located and where the project team will be located.
If the customer is distributed, then understand where their project teams are located and how
workable this is. If the project team is working closely with the customer IT team, but the
customer IT team is on the other side of the world and their business team in a completely
different location, this could become challenging for a highly collaborative project delivery
method like Agile.
Check to see if there are any time zone or other location challenges, e.g. perhaps it's very
difficult to travel to the customer or there are travel restrictions for key people in the project
team.
If customer or partner resources are part of the project team, need to know where they will be
located. E.g. if there are offshore development resources, this needs to be carefully factored
into the planning as Agile is not best suited for offshore development so compromises and
adjustments will likely be required which can increase risk/effort/costs/time.
Language
Understand the preferred language of everyone working on the project, and whether there is
a common language that everyone can speak well.
Also, understand if the documentation is written in the same or different language.
This can have a major impact if people cannot easily communicate both verbally or through
writing.
Culture
Consider the cultures of the people involved in the project and how this might impact the
project and the Agile approach.
For example, in some cultures, it's rude to disagree with someone publicly, so workshops
need to be managed very carefully to ensure people are able to get their views across.
Remote Delivery
Understand if the customer expects or needs an onsite presence or whether they are happy
to work with a remote delivery team.
If the customer needs a lot of onsite support, then need to assess how this will work from
travel perspective based on their location.
If the customer is happy to work with a remote delivery team, then need to assess how well
they can work in this style and whether it's a style they are experienced with. E.g. if customers
are not able to work efficiently and collaboratively with electronic communication tools, this
will quickly become a problem for a project team that's dependent on this form of
communication.
Regulatory Constraints
Check to see if the customer is subject to any regulatory constraints as this can have a
significant impact on a project.
For example, if the customer requires SOX compliance, then they will have much more rigid
documentation requirements and auditing processes that can significantly increase effort and
reduce velocity.
Alternatively, maybe they operate in an industry that requires signed-off functional
requirements and design specifications, such as the pharmaceutical industry. In which case
they may have challenges working with Agile.
Licensing
It’s important to understand what the customer has licensed with regards Hybris Commerce.
For example, if the license is based on certain assumed metrics (e.g. core-based) then need
to be aware in case these change during the project, e.g. architecture, sizing, etc.
Or maybe the customer has licensed only specific Hybris Commerce modules, so other
modules cannot be used without additional cost. So it’s important to understand these as
soon as possible.
Also, understand the licensing model and whether there are any key milestones that the
project team needs to plan around.
Workshop
Once the customer project has been qualified, it’s recommended to have an Initiation phase
workshop on the customer’s premises to discuss and explore the
why/what/how/when/cost/risks of the project, with particular focus on the initial high-level
functional and non-functional requirements that will be used for a high-level estimate and an
understanding of the project scope.
Ideally, it’s best to discuss and explore the why/what/how/when/cost/risks of the project face-
to-face with the customer on their premises. This allows:
Typically this workshop will be around 1-2 days, however, it can be slightly longer/shorter
depending on project size/complexity and the number of people involved. The key is that the
project team receives enough information to estimate high-level effort and create a high-level
project and cost plan.
Prepare Workshop
Preparation is key for the workshop. With only 1-2 days of workshop discussions, it's
important to have an agenda (a list of topics/features to be discussed) and to time-box the
agenda to ensure all topics are covered at an appropriate depth. From a functional
perspective, the objective is not to get detailed requirements, but a high-level understanding
of complexity and prioritization for each feature to enable high-level estimation.
Project, functional, and technical expertise is needed from the project team representatives
for the workshop, so attendees need to be planned appropriately. Appropriately expert and
responsible people from the customer are also required. Also, any important dependent third
parties should also be represented.
If a pre-sales team has previously been involved with the customer, it is helpful to see the
same demos that they gave to the customer beforehand, to understand the customer’s
expectations going into the workshop. Depending on the situation it might also be useful to
have the pre-sales person attend the workshop.
The workshop agenda should be agreed and finalized with the customer beforehand. Topics
should be time-boxed into 1-2 hour slots so that all the material can be covered.
For the functional topics, typically the customer provides a spreadsheet or other document
with their requirements wish list. This can be categorized and used as the functional agenda
structure. If not then a standard list of functional topics can be used.
Typical topics to consider for the workshop agenda are:
Customer’s vision, goals, and objectives of the project, as well as challenges they see today
and potentially in the future
Present the Agile Project Delivery Framework & ways of working
High-level functional requirements & prioritization
Non-functional requirements, e.g. performance, scalability, security
High-level system landscape and integration points
Key milestones, e.g. project start, release roadmap and go-live dates
Third-party dependencies
Data requirements and dependencies, e.g. source/test data and data migration
Project and technical risks
Tooling and ownership
Hosting, infrastructure & environments
Organizational/team structure
Project governance
Testing responsibilities
Stakeholder analysis and identification of all involved parties and their responsibilities
Long-term ownership of solution, e.g. development, maintenance, and support
Responsibility for user experience and creative designs
Run Workshop
Tightly moderate time to ensure all topics are clarified only to a level that enables high-level
understanding and estimating. Sometimes customers focus on certain topics, especially
where there has been a lot of internal debate. It’s recommended the customer continues
these discussions internally after the workshop in preparation for the subsequent Foundation
phase.
Discuss customer expectations on timelines, go-live dates, and scope while avoiding setting
expectations on being able to meet those before proper analysis and planning.
Once timelines and go-lives are known, discuss splitting the overall project into a series of
releases (e.g. 4-6 months in duration). This is to introduce the customer to more frequent
releases rather than a single big bang deployment. When discussing functional requirements
(features), these should be prioritized with the customer into these different releases.
If discussion of a feature starts getting into lengthy discussions and too detailed, it is sufficient
to note it as an area that needs further elaboration which will result in an increased Story
Point size to account for the uncertainty. Plus this also helps identify topics that might need
more time when planning subsequent Foundation phase workshops.
Demos are only needed where they add value and facilitate the objectives of the workshop,
so don’t spend lots of time educating the customer on out-of-the-box functionality as this isn’t
the objective, and time will be taken from more important topics.
Document as much information as possible, this will be needed for later estimations. Most
important are the features to put in the Agile PDF - Initiation Estimation Sheet, but information
related to technical, quality and project considerations should also be captured.
It is helpful to understand budget expectations but be aware that the customer may not want
to provide it and would prefer to receive a cost estimate based on their requested scope not
for the perceived budget.
Dates for customer to provide further input (e.g. diagrams, layouts, click dummies etc.)
Dateforprojectteam to provide estimates and high-level project plans. Set expectations that
these will be high-level estimates subject to further exploration during Foundation phase
workshops.
Agree on potential start dates for the Foundation phase. This is required for high-level project
planning.
Planning
Once the Initiation phase workshops are complete, the project team should have enough
information to plan the project, estimate the effort and provide high-level plans and costs. The
objective at the end of this planning activity is to have a common understanding with the
customer on the why/what/how/when/cost/risks of the project, so that the customer can make
an informed decision whether to proceed with the project and the subsequent Foundation
phase or not.
During this step, the project team takes the information gathered during the qualification and
workshop activities, and all other provided information, and presents the customer with
proposed project plans and costs.
1. Estimation
2. Sizing
3. Planning
4. Presentation
Estimation
It’s important the appropriate people from the project team are involved in providing estimates
for the feature requirements identified during the workshops. This should involved people with
architectural, development and testing responsibilities.
If using Story Points (SP) to estimate effort during the project, it’s recommended these are
used for these Initiation phase estimations. It’s important to start using these as early as
possible, to educate the customer and get them used to SP. Ultimately SP will be converted
to person-days in the cost planning.
Each feature should be estimated using low/medium/high effort so that each feature is given
three estimates to enable estimates and costs to be provided as a range. Note that this is at a
feature level and not at a granular user story level.
Sizing
These will directly impact the costs of the project for the customer from infrastructure,
operational and potentially licensing perspectives.
Therefore these are planned and costed where known, and options presented to the
customer.
Lead times will be important, especially for environment set-up. So these should also be
clearly highlighted and estimated if it is the project team’s responsibility to do so.
Planning
During the workshops the features will have been prioritized, so now with the
small/medium/large Story Point estimates for each feature, a requirements backlog can be
created showing the features planned for each release and the total effort for each release,
expressed as a range.
During the workshops, team structures and resourcing availability would have been
discussed. This allows an estimated development capacity to be created for each sprint and
therefore each release can be sized to accommodate the required scope by using the
estimated or historical velocity for the project team.
Together with the capacity planning and release backlog, a project plan can now be created
showing start/end dates for each release, with go-live and other dependent milestones.
Total costs can now be calculated based on resource and project plans. If using Story Points,
person-days can be calculated by calculating the number of person-days for each sprint.
Presentation
Now that estimates, sizing, and plans are created, they can be presented to the customer,
potentially with different options.
This will likely involve several more discussions and possible revisions to the plans as the
feature scope/timescales are adjusted to fit the customer's needs.
Hopefully, the customer will then decide the project is viable and wants to continue with the
subsequent Foundation phase.
The activities and deliverables remain the same for each Foundation phase, however,
subsequent Foundation phases are typically shorter as they already have a starting point from
the previous Foundation phase.
The below sample high-level project plan shows the first two releases for a project, with the
Foundation phases shown in green.
Unless otherwise noted, this guide will describe the Foundation phase for the first project
release. This will enable the reader to understand the full set of activities. For subsequent
Foundation Phases, some of these activities may be shortened or omitted as appropriate.
The Foundation phase is best delivered as a series of onsite workshops in close collaboration
with the customer, the project team, and other important stakeholders. As well as being the
best format for gaining understanding and discussing the various topics, these collaborative
workshops also enable the various parties to establish personal and working relationships
which are very important for the success of the project.
The following list of activities should be covered during the initial Foundation phase
then revisited during any subsequent Foundation phase as required:
From a functional requirements perspective, effort should be focused on the features in the
current release deferring detailed elaboration of features for all subsequent releases to
subsequent Foundation phases to avoid wasted effort. It is possible that these later features
will either change or be reprioritized as the project progresses, so any early detailed
elaboration will likely be wasted effort and therefore best undertaken only when required.
During the Foundation phase, the customer and project team also need to decide whether the
subsequent optional Exploration phase is required to explore any outstanding risks before
being able to commence with the Engineering phase, or whether the risks are known with
enough certainty to continue directly to the Engineering phase. See Exploration phase for
details.
Agile PDF - Foundation Preparation
Preparation and proper prior planning are very
important for successful Foundation phase
workshops, otherwise, it can become an
inefficient and frustrating exercise for all parties
and the project team will not have all the
information it needs, thereby putting the
Engineering phase at major risk before it even
starts.
The duration of the Foundation phase (from start of workshops until deliverables are sent to
the customer) depends on several factors including:
As a guide the following scale can be used to estimate the duration of the first Foundation
phase, based on the total number of person-days (PD) estimated for the project as a whole
during the preceding Initiation phase (including project management, architecture, business
analysis, development, and testing):
Internal Kickoff
The project team should meet to establish ways of working and roles and responsibilities as
they prepare for the upcoming Foundation phase workshops and project. At this time, the
team should also decide on a Definition of Done (DoD) and Agile PDF - Definition of
Ready (DoR).
Once the duration is known and the onsite/offsite days are planned, the agenda can be
defined and agreed with all relevant parties. As a guide, this should be based on the topics
discovered in Agile PDF - Initiation Workshop, plus any other topics specific to the project.
Buffer workshops should also be planned to address new requirements that are identified
during the workshops and any overruns.
The offsite days can be organized as appropriate, either together at the end of the phase or
mixed with the onsite days. In practice, it’s often more efficient to have some lightweight
documentation effort during or after the workshop days (e.g. at the end of each week), then
consolidate the majority of offsite documentation effort at the end of the phase.
It’s very important both the customer and the project team work together on this agenda, as
often there are resource dependencies or maybe a logical flow that will maximize workshop
efficiency.
These planning activities should be the responsibility of both the customer and project team’s
Project Managers.
As well as ensuring the appropriate balance of numbers, it’s also vital to ensure the
appropriate balance of decision-making and knowledge, on both the customer side and the
project team side.
Typically it’s a good idea for the workshops to be held on the customer’s premises to ensure
availability of the required people from their side, especially for the first Foundation phase.
Additionally seeing how the customer works day-to-day and their working environment also
helps the project team to better understand the customer.
From the project team side, it’s generally not possible or even desirable for the whole team to
attend the workshops, so it’s important to ensure attendance of key and trusted team
members that can represent the whole team in each area.
As a guide the following roles should be considered during the workshops (note that a single
person can perform multiple roles):
Project team:
Customer:
Creative design agency representative (if external party is responsible for creative designs)
Infrastructure representative (if customer Architect cannot cover)
Security team representative (if customer Architect cannot cover)
The project team’s capacity for the project and each release should be calculated during the
Initiation phase and reviewed prior to the Foundation phase to account for new information
and factors. The results of these calculations must be known in advance of the Foundation
workshops to enable reliable prioritization and release planning activities to occur during the
workshops.
For example, if using Story Points (SP) the teams need to know how many SP can potentially
be delivered in each release, so they can plan the appropriate amount of work into those
releases. E.g. if a release has an estimated capacity of 1000 SP, then no more than 1000 SP
can be planned in that release and any additional work needs to be planned in a subsequent
release.
There are three different types of sprints within the Engineering phase:
Set-up sprint (also known as sprint zero) at the start of the Engineering phase
Implementation sprints – the solution is only developed during these sprints so this is where
the capacity needs to be calculated
Hardening sprint at the end of the Engineering phase
The number of implementation sprints within a release is dictated by the customer’s release
go-live date expectations, as the duration for these sprints is fixed from the start of the project
(e.g. typically either 2 or 3 week) whereas the other two sprint types can be more variable
depending on the project (although typically 1-2 weeks each). Therefore only a fixed number
of implementation sprints can be planned within these known timescales.
2. Velocity of Each Implementation Sprint
When using Agile there are different methods used to calculate velocity including estimated
and historical approaches. However, as a guide, the following can also be used:
a) Estimate the SP produced by one fully experienced developer assuming 100% availability
and that they are dedicated 100% to development activities. This is the benchmark developer
and is the maximum SP produced by any one person.
b) Now the produced SP can be estimated for all other developers in relation to this
developer. For each developer resources estimate their % availability, % time allocated to
development activities and their % productivity compared with the benchmark developer (who
is 100% productive). The productivity is typically based on their experience level in relation to
the benchmark developer so that if they are relatively inexperienced they might only be 50%
productive compared with 100% productive benchmark developer. For example, if the
benchmark developer produces on average 15 SP per sprint, and a second developer is also
100% available and 100% allocated to development activities but is only 50% productive
compared with the benchmark developer, they will produce 7.5 SP on average per sprint.
c) Now the potential total SP is estimated per sprint, factor in appropriate non-project time,
e.g. holidays, training, sickness, etc. For example, if you assume 15% of their working time is
non–project time, then multiple the potential total by 85% to get the realistic total (it’s not
realistic to assume there will be no non-project time!).
3. Total Capacity Calculation
Now the estimated SP capacity is known for each implementation sprint, multiply by the
number of implementation sprints to give the total estimated release SP capacity.
Research Topics
As the agenda is being prepared, there may be some topics the project team is unfamiliar
with, e.g. if the customer requires a new Hybris Commerce module that’s only recently been
released.
These topics should be identified as early as possible, and appropriate time allocated to allow
the project team workshop attendees to research and learn about these topics in preparation
for the workshops.
The customer should prepare a business overview for each of the features to be discussed
during the Foundation phase workshops.
The presenter should be a customer representative who is ultimately responsible for the
feature or able to understand/communicate the expected value to be obtained from it, so they
can fully explain the requirements, answer questions in a timely manner, and make any
appropriate decisions related to the feature. In case immediate decisions cannot be made, the
customer representative should own the action to ensure a decision is made and
communicated to the project team as soon as possible.
If there are important technical aspects that need to be presented by someone else, then the
customer representative should be supported by the appropriate person that can fully explain
them, so that they are discussed together with the business requirements.
The customer should prepare a technical overview of any specific technical requirements, e.g.
integrations to external systems, and non-functional requirements related to the solution, e.g.
performance requirements.
The presenter should be a customer technical resource that is able to present the specific
technical/non-functional requirements or limitations as well as the impact the requirement will
have on other systems.
Prepare Demos
In addition to the customer presenting their requirements, the project team should also be
prepared to present the out-of-the-box Hybris Commerce options, standard business user
tools, examples of best practice, and any other relevant material.
Therefore it’s important these are prepared beforehand to provide a smooth and seamless
demo. This might involve setting up local environments on attendee laptops, setting up data,
or whatever is required to independently provide the demo (i.e. in case there is no Internet
access). It’s always a good idea to for two people to have these configured, just in case one
person’s environment isn’t working at the needed time.
An efficient method of capturing requirements during the workshops is using paper cards. The
project team’s Business Analyst will document requirements on paper cards with each card
representing a feature title, sub-feature title (if pre-defined) and requirements tracking tool ID
(if assigned). Paper cards representing features may be pre-populated in advance.
It’s also very important to prepare the workshop room itself to maximize efficiency and
productivity.
Physical Facility
The physical room itself should be planned and prepared appropriately for the workshops to
ensure people are comfortable. Workshops can easily get tiring after many hours/days so it’s
important to keep people as fresh and alert as possible. Cramped, hot and stuffy rooms with
no windows or ventilation can kill energy levels, leaving questions unasked and people just
wanting to leave as soon as possible. So ensure workshop rooms have good ventilation, are
appropriately sized for the planned attendees (and others who may decide to join), and
there’s plenty of water, tea, and coffee available!
Release Wall
It’s important to prepare a ‘release wall’. This is an area of wall space in the workshop room
that is used to display the feature and sub-feature paper cards that are created during the
workshops. This wall is used to create the release roadmap in real-time as the workshops
progress, i.e. the process of prioritizing requirements between releases.
This wall space should be large enough to display the cards and should be separated into the
following areas:
If appropriate and permitted, it may be useful to record the workshop as this allows for project
stakeholders who are unable to attend the Foundation workshops to view the material
presented and for this material to be referenced at a later date if required. If so, it is important
to confirm the participant’s permission in advance and whether any special precautions must
be taken with the resulting material.
Presentation Materials
Workshops should be dynamic with people interacting and collaborating. As such it’s
important there are enough whiteboards and flip charts to allow people to present designs
and ideas as needed. These should also be captured either using cameras or other methods.
Of course, there should also be a working high-quality projector that can be clearly seen by all
attendees. There is nothing more frustrating than people spending lots of time trying to get a
projector working with their laptop, the resolution is poor, color is missing or other problems
that could have been avoided by prior testing of the equipment.
Internet Access
It’s important to ensure attendees have good quality Internet access both for presentations
(e.g. showing competitor solutions) and attendees (e.g. so they can contact non-attendees for
information without leaving the workshop).
The Foundation Phase workshops can be broadly separated into the following activities:
1. Project kick-off
2. Define project governance, organization & structure
3. Define solution goals
4. Define functional requirements
5. Define non-functional requirements
6. Design architecture & system integrations
7. Define environments & tooling
8. Define quality management & testing strategy
9. Release planning & prioritization
Documentation is another important activity that should be done in parallel to the above
activities, ideally either as a dedicated time at the end of each workshop or at the end of each
day or week. This will be dependent on the workshop agenda, how the project team prefers to
work and what fits best for the customer.
These activities do not need to be completed in the above sequence or separately, it’s often
more efficient to combine them where appropriate. The most important factor is they are all
completed properly so that high quality and accurate deliverables are provided at the end of
the Foundation Phase.
Project Kick-Off
The project vision should be presented by the customer (ideally the Project Sponsor) at the
beginning of the Foundation workshops and include the history, goals and expected business
value to be obtained from the project. To effectively kick-off a project it is important to ensure
that all parties and stakeholders understand the shared objectives.
During this workshop, the high-level project plan defined during the preceding Initiation Phase
will be presented to the team, as well as the specific goals for the current upcoming release.
This sets the context for the subsequent workshops.
The project governance, structure, and organization should be defined during the Foundation
workshops incorporating all project stakeholders. Roles and responsibilities should be
documented and clearly communicated, for example, responsibility for frontend code, cross-
browser compatibility testing, performance testing, the definition of acceptance criteria, and
infrastructure. This is documented as a RACI matrix in the Project Management
Definition deliverable.
Regular project meetings and communication channels should be defined and agreed. For
example:
Understanding the goals of the new solution is very important as these should be used as a
reference point for decision-making, e.g. during requirements prioritization. Therefore it's
important these are understood upfront during the Foundation Phase workshops, so everyone
is aligned. It's equally important to identify if goals are unrealistic and mitigate these
expectations as early as possible, resetting goals appropriately.
Pain points
Revenue / key performance indicators (KPIs)
Competitive advantage
Additionally, it's equally important to understand the consequences of NOT doing the project
and building the new solution. Often these are very powerful drivers in themselves, and it's
very important to understand these, so it's recommended these are also explored during this
workshop.
Pain Points
Even if there's no existing solution, there will likely be pain points in the customer's business
that the new solution may be able to resolve, perhaps that the customer hasn't considered
and may be identified as they explore the new solution in more depth.
Revenue / KPIs
Revenue targets and KPIs typically go hand in hand with goals and objectives, and may even
be outlined as part of the success criteria. These metrics can also be helpful to determine the
size and scale of the solution, along with projected growth. Typically these are marketing,
sales, or traffic related.
Key metrics to establish if possible include:
Daily/weekly/monthly/yearly sales
Gross and net
By volume and amount
Average order value (AOV)
Average order size (number of items)
Margins ($ and %)
Conversion rate
Abandonment rate
Bounce rate
Site visits
Simultaneous
Daily
Weekly
Traffic source
Native
Search
Paid-search
Pay-per-click
Email/promotion
Referral
Time-on-site and number of page visited
New vs. returning customers
Stock/inventory levels
Competitive Advantage
Understanding the customer's competitors and their strategy to compete against them is very
useful. This can be done by:
1. Outlining all known and up-and-coming competitors and ranking them appropriately, e.g.
regarding their eCommerce strengths/weaknesses.
2. Explore how they compete with each competitor, and whether there are areas, they are trying
to catch them in, as well if there are areas they are trying to be an innovator or gain a
competitive advantage.
3. Ask the simple question: what is the best thing the customer's biggest competitor is doing that
they aren't?
A thorough understanding of the customer's competitive situation can help the project team
guide the new solution to maximum advantage, e.g. if a competitor is particularly strong or
weak in an aspect of their eCommerce offering, these can be used as reference points during
subsequent requirements analysis workshops.
During the Foundation workshops, the customer’s business and technical representatives
further elaborate upon the features for the current release as defined during the preceding
Initiation phase. These sessions will be scheduled as defined by the workshop agenda that
was agreed before the workshops commence.
This guide will assume paper cards are being used to capture requirements during the
Foundation phase, although other methods can also be used.
Feature Presentations
The following presentations are required to communicate the business and technical
requirements of a feature:
Business presentation:
The customer representative responsible for the respective feature should communicate all
business requirements. Examples may include:
Feature overview
Expected business value
Mock-ups (screenshots) or layouts
Technical presentation:
The customer representative and/or the supporting technical authority should communicate
any known technical considerations relating to the requested feature. Examples may include:
Rules/restrictions
Entity relationship diagrams
Data flow diagrams
System diagrams
Specific non-functional requirements
Analytics specification
Technical dependencies
Technical value to help subsequent prioritization
The business and technical presentations are often combined to make sessions more
efficient.
Q&A Session
Following each presentation, a question-and-answer (Q&A) session allows the project team to
immediately clarify requirements and possibly suggest alternative options to ensure the
customer’s requirements are fully understood, and the best solution is decided. It’s important
to do this while the information is fresh in people’s minds and the relevant people are
available. This is also a good opportunity for the project team’s Business Analyst to clarify the
information captured on the paper cards during the presentations.
Requirements Documentation
Once the project team can understand the requirements to an appropriate depth, then the
requirements can be documented. Further elaboration of each requirement (e.g. acceptance
criteria) will be defined later during the Engineering phase as needed. This further level of
detail is not required at this stage. The project team only needs to understand the
requirements to enough depth to be able to estimate effort/complexity, understand value, and
any dependencies.
During the business and technical presentations the project team’s Business Analyst should
decompose features into sub-features and document each on paper cards. A card should
also be created displaying the associated feature title for use on the release wall (if not
prepared in advance).
If a feature is deemed to be too large or complex, then the project team may split the feature
into separate features. This can only be achieved if each feature, once split, still provides
value and can be delivered independently.
INVEST
The acronym INVEST can be used as a checklist to assess the quality of a feature, sub-
feature or user story. This suggests a well-defined feature/subfeature/user story should be:
This should be used a guide. However, it’s not always possible to follow exactly, e.g.
sometimes sub-features are dependent on another sub-feature being implemented first.
Here is an example sub-feature card showing how paper cards can be used to document
requirements:
The following example illustrates the relationship between a feature and a sub-feature in
paper card form:
Dependencies between sub-features can be visualized through the use of stickers on the
cards that display appropriate comments. It is important that dependencies are documented
to avoid features being dependent on other features being selected during release planning.
Estimation
Once each feature has been decomposed into sub-features they can be estimated. If
possible, ideally the estimations are done in view of the customer, so they can immediately
answer questions coming up during the estimation discussions. This not only ensures that all
information is fresh in the minds of the project team as they are estimated but also that each
feature is fully documented before estimation while displaying transparency during the
process. Sufficient time should be allocated for estimation activities to occur following each
feature presentation.
Estimation Approaches
There are different approaches to estimation, and these can vary depending on the project
team’s preferences. Here we present a recommended approach that has been successfully
used in many projects (commonly referred to as ‘planning poker’):
1. With all people in view of the sub-features to be estimated, a designated Scrum Master
facilitates the estimation activities.
2. The Scrum Master or Business Analyst should provide an overview of the sub-feature.
3. The Scrum Master decides whether the team is ready to estimate:
a. Ensures that all attendees are comfortable with providing estimates. If any attendees are not
comfortable with providing an estimate, then further discussion should occur.
b. If further clarification or feedback is still required and the customer is unable to provide
enough information to enable the project team to estimate then the feature paper card (and
hence all subsequent related sub-feature cards), should be marked as blocked until further
information can be provided. Once sufficient information has been provided then the relevant
sub-feature/feature should be revisited either during a separate consolidation workshop or ad-
hoc as required.
4. During the estimation activity the project team focuses on a single sub-feature and estimates
using planning poker:
a. Provide a five-second countdown to select estimates
b. All people display their estimates at the end of the five-second countdown
c. Read each estimate aloud while assessing the range of estimates from the lowest to highest
d. Request feedback from those who have provided the lowest estimate
e. Request feedback from those who have provided the highest estimate
f. Refine estimates as a group and reach a consensus
g. Document the agreed final estimate on the associated paper card
Once the sub-features have been estimated, the paper cards should be placed on the release
wall within the ‘To be scheduled’ area underneath the associated feature title card.
Non-functional requirements (NFRs) are equally important (if not more important) than
functional requirements. You can have the most perfect functional solution in the world, but if
it isn’t accessible because it can’t handle the number of users, not only does it not work, but it
can also have serious impacts on brand perception, lost customers and ultimately revenue.
Therefore the project team needs to ensure non-functional requirements are captured during
the technical presentations. Typically this is the role of the project team’s Architect to ensure
these are captured. Additionally, there should be dedicated workshop sessions specifically to
discuss the customer’s non-functional requirements for the solution. These usually focus on
what is commonly called the ‘ilities,' e.g. scalability, maintainability, operability, upgradability
and so on. It’s important these are covered separately as NFRs tend to overarch all individual
functional requirements.
NFRs are a vital input into the architecture and infrastructure workshops, and they can also
have a significant impact on planning and costs. Additionally, NFRs need to be known before
development can start (so before the Engineering phase), as they have a significant influence
on architecture, technical design decisions, and testing effort. So it’s essential these are
thoroughly captured during the Foundation phase and planned in from the start of the project.
The project team’s Business Analyst and Architect should document non-functional
requirements on paper cards in the same manner as sub-features so that they can be
prioritized and planned during the Foundation workshops. Non-functional requirements may
also be documented within acceptance criteria of a feature/subfeature to ensure that they are
met if essential for implementation. The information collected should form the basis of the
Non-Functional Requirements document deliverable to be provided by the project team’s
Architect.
Performance
Scalability
Capacity
Availability
Maintainability
Security
Regulatory
Rather than try to estimate each NFR individually which can be challenging, a better
approach is often to create a buffer to incorporate groups of NFRs together, e.g. a Story Point
buffer. For example, a 100 Story Point buffer for performance can be assigned to the release,
then used up as the Engineering phase progresses through the sprints depending how much
effort is spent on performance in each sprint. This would then also count towards the
completed Story Points in each sprint and therefore also the sprint velocity and release goal.
Design Architecture & System Integrations
High-level physical and logical architectures and integrations with third-party systems should
be investigated during the business and technical presentations. Early design activities such
as core data modeling activities can also be undertaken where it adds value to the
workshops, e.g. facilitates discussions or explains concepts. For example, this is commonly
done for catalogs, products, content, pricing, etc.
The project team should pay particular attention to any required system integrations and
ensure that the impact of any such integrations is sufficiently understood. If the project
involves integrating with a third-party system which is not managed by the customer or project
team, then representatives from the third-party should be in attendance during the relevant
feature business and technical presentations to provide additional feedback if required.
Infrastructure environments and tooling are essential to the project. For example, if
infrastructure environments are not ready on time they will have a major impact on overall
project timings, e.g. if there are no test environments to deploy to then no testing can occur,
and development is held up. There is always a lead-time to setting up these environments, so
they need to be specified as soon as possible, and timings built into the project plan.
It is recommended that the project team works closely with the customer to define required
infrastructure and environments (e.g. development, test, pre-production, production). The
requirements for these environments are likely to be dictated by the NFRs and prioritization of
features.
Tooling is also a very important topic that can easily cause delays and frustration if not
properly considered and planned up-front. For example, the project management tools (e.g.
Jira), the development tools (e.g. IDE, continuous integration, source code repository), testing
tools (e.g. performance testing), etc. There is always effort to set these up at the start of a
project. Changing them mid-way through a project is very time consuming and will likely
cause significant delays.
It’s very important to define and agree how the solution will be tested throughout the project to
ensure the quality goals are met. Ultimately the customer needs to decide the quality goals as
it’s an investment that requires effort and therefore budget. However, it’s strongly
recommended this is properly considered and planned. Quality needs to be baked-in from day
one; it’s much more expensive to try and fix quality later.
Specific workshops should be allocated specifically to cover the different types of testing and
ensure responsibilities are agreed. A RACI matrix in the Quality Assurance Definition is a
good method to document who is responsible, who approves, who is consulted and who is
informed.
Testing topics include:
Feature tests
Integration tests
Acceptance tests
Deployment tests
Performance tests
Cross-browser compatibility tests
Post-sprint acceptance tests
System integration tests
Authorization tests
User acceptance tests
Security tests
Test data should also be discussed and planned during the workshops. Preparing test data
can take a significant amount of effort. The quality of the data is also very important, and data
cleansing can also be very time-consuming. This can be a major source of delays and quality
issues later if not planned properly.
Infrastructure environments are also a key input here. It’s essential that appropriate testing
environments are available when required. Tooling is also a key consideration and needs to
be discussed/agreed with the customer. The defect management process should also be
agreed with the customer.
This information forms the basis for the Quality Assurance Definition (QAD) deliverable, to be
published by the project team’s senior testing representative. The QAD template contains
additional information about these testing topics.
System integration testing and integration testing test how the solution interacts with other
systems, but integration testing is performed by the project team and may use mocked
integration so that it is not impeded by external systems. Whereas system integration testing
is performed by the customer and also includes testing of interactions in the external systems
that cannot be simulated through mocks.
Once features/sub-features are present on the ‘To be scheduled’ area of the release wall the
project team, and customer can collaboratively begin the prioritization activity. This can be an
on-going activity or may be undertaken once all features/sub-features have been estimated. It
is preferred that this is an on-going activity to ensure the customer is aware of the running
total of the estimates produced to compare this figure against the targeted release capacity as
the Foundation workshops progress.
The project team and customer should prioritize the features within the ‘To be scheduled’
area of the release wall, moving the associated paper cards to reflect the designated priority
of each feature while considering all previously highlighted dependencies.
With the capacity for each release displayed on the release wall with the must-have/should-
have subtotal split, and estimates documented for each feature/subfeature, and the ‘To be
scheduled’ cards prioritized, the customer can designate sub-features as must-have or
should-have and begin to move the cards on the wall to create the release roadmap, keeping
within the capacity and agreed must-have/should-have ratio proportions (ideally 60/40 ratio
%).
Once the targeted release capacity is reached with the appropriate must/should-have ratio,
the release roadmap is now planned. The targets should be met exactly or slightly under,
never exceeded.
With this release roadmap, the customer and project team now agree on the initial plan for
what will be developed for each release, the prioritization within each release and the agreed
contingency within each release (the should-haves). Of course, this is only a plan, and the
content of each release is not fixed, and the capacity target is also variable as it’s only been
estimated and is subject to a wide variety of factors, hence the need for contingency. The
customer can also define new requirements and change prioritization during the release with
the agreement of the project team. So the release roadmap constantly evolves as the project
continues.
Each sub-feature card should then be marked with the planned release number and whether
it’s a must-have or should-have.
Sub-feature card
The following diagram displays an enlarged view of the completed release roadmap with
features preselected for an example Release 1, split into ‘must have’ and ‘should have’ along
with features that have been moved to a future release.
Once the release roadmap has been agreed and published, it should be distributed to all
members of the project team for further review before final confirmation with the customer as
final deliverable of the Foundation phase. This is a critical input into the Engineering phase,
so it’s important to check thoroughly and get buy-in from the whole project team.
1. Project planning
2. Release planning
3. Cost planning
4. Risk analysis
Project Planning
Project planning refers to the planning activities required to schedule the proposed release(s)
of a project. The project plan will likely include activities dates such as:
Release start/end
Phase start/end within each release
Sprint start/end within the Engineering phase
Acceptance testing start/end
Go-live
Performance testing
Security testing
Content creation (see cutover planning and preparation)
Data migration (see cutover planning and preparation)
Additionally, the project plan will show dependencies and associated activities and
milestones.
The project/release plan initially created during the Initiation phase should be refined to now
include fixed release and phase timescales together with associated go-live dates. The plan
may have been adapted during the Foundation Phase workshops to account for agreed
changes to capacity and timescales, as the originals would have been based on some
assumptions that might have changed. In some cases, more than one plan may be presented
to provide the customer with a number of options.
Release Planning
During the Foundation phase workshops, the requirements will have been documented (e.g.
using paper cards), estimated, prioritized and planned using a release wall to create a release
roadmap.
This will now be formally documented to define the planned requirements for each release,
appropriately categorized as must-have/should-have requirements, then prioritized.
The agreed release roadmap and associated requirements are provided as a Foundation
Phase deliverable called the Prioritized Requirements List (PRL).
Cost Planning
Cost planning activities should occur in order to provide the customer with an estimated cost
for the whole project and for each release. The process for calculating costs will vary
depending on various factors but is mainly dependent on resource costs.
These costs are provided as a Foundation phase deliverable called the Cost Plan.
Risk Analysis
Throughout the Foundation phase workshops, the project team will identify risks from different
perspectives, e.g. technical, project management, quality. These need to be clearly
communicated and openly discussed with the customer and factored into any planning. The
project team’s Project Manager should capture all identified risks with probability, impact
and mitigation plans.
These risks are delivered as a Foundation phase deliverable called the Risk Register.
Next Steps
Ideally, the Foundation phase workshops are enough to fulfill the objectives of the phase, to
identify/mitigate risks, and give both the customer and the project team enough confidence
and certainty to proceed with the Engineering phase.
However, sometimes it’s decided that a subsequent Exploration phase is required to explore
remaining significant project risks in more detail before starting the Engineering phase. The
output of this Exploration phase will then be used to appropriately update the Foundation
phase deliverables to provide the customer with updated information to be able to make the
go/no-go decision on whether to proceed with the Engineering phase.
Description
Exploration phases tend to be relatively small and very targeted on a specific aspect of the
project. The phase duration can vary widely from a few days to a few weeks. The scope can
also vary widely, as it really depends on the areas of uncertainty and risk, these will always be
different from project to project.
For example, if there is a significant area of technical risk the team might decide to perform a
proof-of-concept (PoC) in an Exploration phase to explore this risk, to allow them to better
understand how to proceed with the main project. This PoC could then be used as the basis
for development during the Engineering phase, or a throw-away exercise, depending on the
approach taken:
Throw-away PoC – This is typically the fastest approach as the focus is to validate something
very specific, there is no focus on quality, reusable design, extensibility, maintainability etc.
However aside from the knowledge gained, the work produced is of very little value.
Re-useable PoC – This is usually significantly more work as it will form the basis for the
solution and the starting point for development during the Engineering phase, therefore no
work produced is wasted. However, it needs to be properly architected, designed and tested.
This is more costly than the throw-away approach as more effort and time is required.
Due to the wide variations of the Exploration phase, unless it’s a very well specified re-
useable PoC, it’s often not possible to define specific new deliverables, however, the
knowledge gained should be used to update the deliverables from the preceding Foundation
Phase.
In practice, Exploration Phases are rarely required for Hybris Commerce projects. They are
more typically used when building a solution from scratch, where there is a lot more technical
uncertainty and risk. With Hybris Commerce projects, the project team is building upon a
mature and stable platform so this risk is greatly reduced already. However, there are valid
cases where an Exploration Phase might be needed, for example, to explore:
Where the Hybris Commerce platform is being pushed well beyond the boundaries of its
design, e.g. to support exceptional high performance, transactional, or other non-functional
requirements.
The complexity of a major new integration with a critical external system.
Designing and modeling of complex data structures/mappings
The ultimate goal of the Exploration Phase is to find solutions, mitigate risks, update
estimates, re-schedule scope and re-plan timescales as necessary so to provide the
customer with the needed information to make a go/no-go decision on the Engineering Phase
and the project in general.
However, the Exploration Phase should not be used as an extension of the Foundation Phase
where functional/non-functional requirements are not clear, or where some of the other topics
in the Foundation Phase have not been covered in appropriate depth for some reason. In this
case, the Foundation Phase should be extended. The purpose of the Exploration Phase is
very different, it assumes the deliverables from the preceding Foundation Phase are
complete, and only specific area(s) of risk need further exploration to give the customer and
project team the confidence required to continue with the Engineering Phase and possibly the
project as a whole.
Sometimes the customer or project team may identify significant technical risk during the
Initiation Phase, and it might be decided that a PoC is needed before starting the Foundation
Phase. This could be because:
The risk is significant and the customer does not want to invest in the overhead and cost of
running a Foundation Phase if there’s a relatively high chance the outcome of the PoC will
mean the customer will not continue with the project.
There is a significant risk that the outcome of the PoC will majorly affect the functional or non-
functional requirements, which could potentially invalidate much of the work done in the
Foundation Phase.
As with any PoC, it needs to be decided whether it will be re-usable or throw-away. If it’s
throw-away then the PoC should be delivered in an appropriate manner during the Initiation
Phase, and the outputs used to create the high-level estimates, plans, etc. provided at the
end of the Initiation Phase as normal.
If it’s a reusable PoC and there is considerable development effort, then the requirements for
the PoC need to be properly captured so it can be built and tested appropriately. Therefore it
should be managed as a smaller up-front project, with a smaller reduced scope Foundation
Phase specifically focusing on the PoC requirements, followed by a small Engineering Phase,
perhaps without some of the formalities of a full-blown Foundation/Engineering Phase,
depending whether the PoC requires the formality of acceptance testing, warranty and
potentially deployment to a production environment. If the results of the PoC are considered
satisfactory, then the full Foundation Phase would start as normal.
Essentially, the Engineering Phase is based on Scrum, the most commonly known Agile
method. However, whereas textbook Scrum is designed for continuous software development
internally within a single organization, here it’s used within the context of a release, which in
turn is within the context of a project, and often where the project team and customer belong
to different organizations and the project is being delivered on a contractual basis. Therefore
the textbook Scrum approach has been adapted within this phase to cater for these additional
factors.
Note that in Scrum iterations are called ‘sprints’. These terms can be used interchangeably
during the Engineering Phase as they have the same meaning, however, it’s recommended to
use ‘sprint’ because that communicates to everyone that the teams are using a Scrum-based
approach.
The sequential activities of the Engineering Phase are:
1. Set-up sprint (commonly called sprint zero) – preparation for the subsequent implementation
sprints, e.g. set-up tooling, environments, and test data.
2. Implementation sprints (multiple) – fixed duration software development iterations, i.e.
analyze/design/build/test.
3. Hardening sprint – finalization of the software produced in the previous implementation sprints
in preparation for UAT.
4. User acceptance testing (UAT) – formal customer acceptance testing of the software.
Typically there are also a number of parallel activities that are often planned as part of this
phase, although often they are managed as a separate cutover activity, for example, end-user
training. However, they are all dependent on the software (and therefore deliverables) of this
Engineering Phase so need to be planned together.
The below example plan shows typical Engineering Phase activities within a single release:
This plan is only an example and timings can vary between projects, however, it shows
general good practice:
System integration testing starting after Sprint 1 until the end of UAT.
Performance testing starting after Sprint 2 until halfway through UAT.
Security testing starting midway through Sprint 4 until a couple of weeks into UAT.
The timings of the above parallel testing activities will vary from project-to-project as they are
all dependent on what has been developed, test data and availability of test environments and
resources. However, they are all very important and need thorough up-front planning and
continuous tracking and management. It’s essential they all start early enough to allow
appropriate time for feedback/changes to be incorporated in the implementation sprints.
There are also other parallel activities as mentioned earlier, however, these are not shown on
this example plan as they are much more dependent on the project. The example plan just
highlights the most common parallel activities that should be considered as a minimum for
every project.
The example plan below shows the set-up sprint highlighted in red:
The duration of the set-up sprint will vary depending on the project, however, it’s usually 1-3
weeks for the first release. It’s important to ensure there is adequate preparation time
because otherwise, the project team can be is significantly blocked during the first
implementation sprint, which immediately puts the team under unnecessary pressure for the
rest of the release.
The set-up sprint is usually needed for the first release of a project, however, it may not be
required for subsequent releases if these next releases are continuing immediately after the
previous release with little change. If a subsequent release requires significantly different
infrastructure, tooling or technologies then another set-up sprint may be required.
Usually, no functional development occurs during this sprint, however, sometimes this is
useful, for example, if a core feature is needed otherwise it blocks all other development.
The specific activities of the set-up sprint will vary depending on each project, however, it will
typically contain the following types of activities:
Infrastructure Set-Up
Development/test environments
Continuous integration environment
Source code repository
Code review tools and process
Software package delivery & deployment process
Development Set-Up
Knowledge
Sharing the knowledge gained during the Foundation Phase with the whole project team as
many people will not have attended the Foundation Phase workshops
New tools learning/training if the project team is unfamiliar with the selected tools
User story and acceptance criteria sign off
Provision of test data
Interface specifications
Page layouts
Technical design discussions and alignment
Tooling Set-Up
Complete the project task tracking tool set-up (if not already completed during the Foundation
Phase, e.g. Jira)
Project file sharing repository
Project knowledge sharing tools, e.g. wiki
Performance testing tools
Test automation tools
Agile PDF - Engineering Implementation Sprint
The above plan shows five 3-week implementation sprints. The recommended number of
implementation sprints within an Engineering Phase is 4-5 sprints (if sprints are 3 weeks) to
optimize efficiency and productivity:
Too few and the project team doesn’t get enough time to build momentum and iron out the
inevitable inefficiencies that exist in any project team when they get started. The team also
takes at least a couple of sprints to get into a natural productive rhythm (also called cadence).
Too many sprints and inefficiencies start to creep back into the project team as the new
software being prepared for release becomes ever larger, e.g. increasing the amount of
testing effort, and the team naturally becomes less energized working in the same way for a
long period with the constant pressure of achieving sprint targets.
The recommended sprint duration is 2-3 weeks depending on the project context:
The shorter the duration, the greater the frequency and potential overhead of the start/end
sprint activities, which also prevents the team getting into a natural productive way of working
in each sprint, especially if it’s a distributed team.
The longer the duration, the less frequently the customer sees the resultant software, so there
are fewer feedback/testing cycles. It also has the greater chance for inefficiencies to creep
into the project team as sprint targets become too distant which risks creating a mentality of
taking it easy at the start of the sprint, then rushing at the end. It’s much better to have a
sustainable pace from start-to-finish that requires appropriately spaced sprint start/end points
to check/reset goals.
The implementation sprint duration should always be agreed during the Foundation Phase,
and it should remain fixed for all sprints in a single Engineering phase (except the setup and
hardening sprints). It’s also highly recommended to keep this same duration for all
subsequent Engineering phases, as having a constant duration allows the team to optimize
their ways of working to maximize productivity and minimize inefficiencies. They know
naturally what amount of work feels right, how to time that work, and how to self-organize.
This rhythm is very important, it becomes the heartbeat of the team, and allows business
users on the customer side to also get into a rhythm so they can plan around the regular
sprint activities because they know when a software package will be available for their testing.
Fixed sprint durations also makes reporting and tracking much simpler and more transparent
as velocity can be monitored more easily.
The sprint duration should never be changed mid-sprint, even if the target is not met or if user
stories or tasks are almost but not quite finished. These sprints are tightly time-boxed to
ensure the impact on overall release and project timelines are not changed.
The number and duration of implementation sprints are also important because they drive the
potential go-live dates of the project. The more sprints, the more software that’s produced, the
longer the time needed for hardening and UAT. So these also need to be balanced with any
external dependencies and required customer go-live dates.
1. Sprint pre-planning
2. Sprint planning
3. Sprint execution
4. Sprint review
5. Sprint retrospective
6. Post-sprint customer demo
7. Post-sprint customer testing
Sprint pre-planning needs to occur one sprint ahead and be completed before the start of
each implementation sprint. This is very important; otherwise, sprint productivity will be
significantly impacted because instead, this preparation work will occur during the sprint itself,
which will inevitably create inefficiencies as people are blocked waiting for information or as
new dependencies are identified.
a) Calculate the sprint target capacity in Story Points based on the project team’s
availability and historical or estimated velocity. This should account for the capacity
differences per sprint (e.g. due to holidays, training, resource allocation, etc.). This task is
typically performed by the project team’s Project Manager, then presented and explained to
the project team during preparation and planning activities. It’s very important the team accept
this sprint target capacity as they need to commit to achieving it, and maybe it’s adjusted after
feedback from the team.
b) Check the sum of the Story Points delivered in previous sprints in the release so far,
plus the sum of Story Point targets for all remaining implementation sprints still equals
the overall Story Point target for the release that was calculated during the Foundation
Phase. If not then potentially the release target needs to be revised to ensure it remains
realistic. This is the responsibility of the project team’s Project Manager.
c) The next highest priority backlog items are reviewed and selected from the
Prioritized Requirements List (PRL) based on their business and technical priority,
must-have/should-have categorization, dependencies, and resource availability.
Features and sub-features are converted into user stories. The story points distributed such
that the sum of the user story points equals the original total of the feature. Tasks are also
reviewed and may be assigned story points, for example, a performance test task for a sprint
could take some points from the performance test story points for the release.
d) Story backlog refinement is where the user stories and tasks are elaborated with
additional information including full acceptance criteria, testing information, and an
initial design.
e) Customer approval of acceptance criteria. The refined user stories and tasks are
reviewed and approved by the customer.
f) Before a backlog item enters the subsequent sprint planning activity, it should meet
the project team’s Definition of Ready (DoR) to ensure it is ‘ready’ for the sprint. The
DoR ensures that all necessary pre-requisites have been met before a task being scheduled
in a sprint. If the DoR isn’t met, it shouldn’t enter the sprint. See the Agile PDF - Definition of
Ready deliverable for more details.
g) Prepare the sprint by selecting all user stories and other backlog items for the
sprint. Although not typical for Agile projects, this can also include some task
assignments as it can sometimes be valuable to do some advanced planning to assist
in the selection of tasks for the next sprint so that specialized skills are leveraged. This
can be done via a physical board and shared with remote team members and customers as a
photo or through a project task-tracking tool.
2. Sprint Planning
Once sprint pre-planning is completed, the project team is ready for sprint planning.
This is officially the start of the sprint. Its purpose is to assess the pre-selected tasks
and discuss the requirements of each task as a group to check dependencies, assign
individual resources to tasks if not pre-assigned and ensure that each task is
sufficiently understood before commencing work. All members of the project team should
attend sprint planning.
Typically sprint planning is performed as a single time-boxed meeting 1-2 hours in duration,
depending on team size and assuming appropriate sprint preparation beforehand. If this
meeting takes significantly longer, it’s likely preparation wasn’t completed properly.
The sprint planning meeting typically includes the following activities:
a) Overview of the sprint’s Story Point target and assumed resource availability provided by
the project team’s Project Manager as prepared during sprint preparation. If necessary, the
project team members can provide feedback or raise concerns that can then be incorporated
into the plans as appropriate, however, this should be avoided with proper sprint preparation
as amending plans is inefficient, and wastes effort already spent during sprint preparation.
It’s very important the team buys into and commits to the target to ensure maximum
motivation to achieving the target. If teams do not believe the target is realistic, it will likely
have a significant impact on motivation and therefore productivity. Pushing the team to
achieve unrealistic targets with significant overtime might work in the short-term, however, is
well-proven to create much greater longer-term negative impacts, e.g. quality issues,
demotivation, tiredness, attrition, etc. Therefore it’s very important the target is realistic while
also being in line with the overall agreed release target.
b) Sprint features, user stories, and tasks should be presented individually. This may include
layouts, mock-ups, click dummies, etc. This task is undertaken by the project team’s Business
Analyst with the Architect and Lead Developer providing technical input as appropriate. The
functionality is reviewed by the team and elaborated as required. The story point estimate is
reviewed, so that team members can raise a flag if they think the estimate is low based on
what they have learned since the original estimates provided in the Foundation phase.
c) Technical planning for the sprint is undertaken by the project team’s Architect and
development team.
d) To motivate the team, it is a good idea to assign a reward for meeting the Story Point target
at the end of the sprint e.g. a team lunch, dinner or other favored activity.
Business Review
A Business Review is a new practice supporting features development during the Engineering
Phase. Each Story implemented during any Sprint should be reviewed collaboratively by the
Business Analyst, Developer and a QA resource in a Business Review meeting.
A Business Review should be tracked as a sub-task under their respective Story in JIRA.
Sub-task assignee should be the Business Analyst.
1. Business Analyst
2. Developer responsible for Story implementation
3. QA responsible for Story testing
4. Client/Customer Representative (optional as might be too difficult to schedule)
During the meeting Story description and Acceptance Criteria are read out loud. Questions
and concerns are answered or tracked for further clarifications.
In the case of front-end Stories, all wire-frames, models and other types of designs should be
reviewed.
It is recommended that a Business Review take no longer than 15 minutes. If the meeting is
running over it might be an indicator of a too high level of uncertainty and misunderstanding
around the requirements. In such a case the Business Analyst might consider removing
the Story from the current Sprint until outstanding issues are clarified. The Business
Review sub-task should not be closed.
3. Sprint Execution
Sprint execution is the majority of time spent during the implementation sprint and is
focused on the completion of the user stories and tasks selected during the sprint
planning. Completion means each passes the Definition of Done (DoD) test which is a
checklist agreed by the whole team at the start of the project (and continuously
reviewed/improved throughout the project) of what is needed for a task/user story to be
considered ‘done’ and therefore allow the Story Points allocated to the task/user story to be
added the total of Story Points delivered for the sprint. See the Definition of Done deliverable
for a list of what should be included in a DoD.
During an implementation sprint execution there are various collaboration and meeting
events:
The daily stand-up should be held every working day ideally in the morning. For remote
teams, this can be done via screen sharing/phone. Co-located teams should have a proper
meeting room or can simply do it within their general working space if the entire teams sit
together and do not disturb others. The duration depends on team size but should not extend
15 minutes.
The weekly working group meeting is to track the project status within each of the project’s
workstreams represented by key representatives – those who are closely involved in the
running and shaping of the project, i.e. the customer, project team and other 3 rd parties e.g.
hosting providers, design agencies, etc. Any concerns should be raised so that risks can be
highlighted and managed. This meeting should occur once a week and with duration of 0.5-
1.5h depending on team and project size. Both the customer and the project team’s Project
Manager should summarize all input from their respective workstream representatives (plus
appropriate 3rd parties), and document them in a simple shared report before the meeting.
The meeting itself should be done via screen sharing/phone as participants will join from
various locations. The project team’s Project Manager should drive and moderate the
meeting. However, each workstream owner should present his status to the group and
answer questions that may come up. After all, streams have presented their status the group
should review the risk log and update status, track new risks, etc. Again the project team’s
Project Manager should moderate this.
Instant communication channels are useful for all teams, but especially for distributed
teams (e.g. Skype, IM).
Other meetings can, of course, be planned as needed, depending on the project context. The
key consideration is they must efficient and provide value in line with the goals of the project.
During sprint execution, progress is constantly monitored using physical task boards and/or
electronic project tracking tools (e.g. Jira). This helps the project team and customer know
where the team is in terms of delivered Story Points, the status of tasks/user stories/sub-tasks
and to identify bottlenecks.
At the end of sprint execution, a software package is created and delivered to the customer.
This involves:
1. Code freeze
2. Packing, branching
3. Release documentation
4. Deployment support
5. Report showing completed users stories/tasks and their acceptance criteria (signed-off before
sprint)
6. Report showing signed-off non-functional requirements (NFRs). These should already have
been agreed during the Foundation Phase, but are provided here again in case changes have
been agreed during the sprint and to avoid any ambiguity.
4. Sprint Review
The sprint review occurs at the end of the implementation sprint. This is an opportunity
for members of the project team to present completed user stories and tasks to the
rest of the team. Typically it is performed as a single time-boxed meeting 1-2 hours in
duration.
Each developer should present what they implemented during the sprint. This must be
prepared in advance of the sprint review (e.g. test data, login credentials, the method to
receive email and whatever else may be required). Having developers present their work is a
good way to increase motivation and quality during the sprint as people naturally want to
show something significant to the rest of the team. It’s also a good exercise in improving their
communication and presentation skills.
This meeting is usually internal. However, if the customer or other external developers are
members of the project team, they should be included. The customer Project Manager and
Business Analyst may join, preferably in a listen-only mode. There is a separate post-sprint
customer demo meeting where the project team’s Business Analyst presents the completed
user stories implemented during the sprint to the customer from a functional/business point of
view.
5. Sprint Retrospective
After the sprint review meeting, the whole team gets together for a sprint retrospective
meeting. This is usually time-boxed for 1-2 hours. It’s an opportunity to reflect on the
sprint to highlight achievements and discuss what went well and what can be
improved in the next sprint. This activity officially marks the end of the implementation
sprint, after which the team is ready for the sprint planning and start of the next sprint.
a) Reflect on what went well during the previous sprint and define whether any actions
are required to maintain the positive experiences.
b) Discuss areas that can be improved and what can be done to improve them. Actions
should be clearly defined with individual resources assigned to each.
c) Review the actions decided from the last sprint and whether they were achieved.
d) All feedback and agreed actions should be documented and be accessible to the
project team.
The post-sprint customer demo is where the completed user stories and tasks are
presented to the customer and other relevant stakeholders. This is similar to the previous
sprint review. However, it’s a more polished presentation that is well prepared and ideally
performed on the customer's test environment using the deployed software package prepared
at the end of the sprint, and demonstrated using the customer’s test data.
This demo should be presented by the project team’s Business Analyst and may be recorded
for later use as training material. It will usually occur after the end of the implementation sprint
as extra preparation is required which takes additional time.
Each user story/task will be presented together with their acceptance criteria, and each will be
demonstrated to show the acceptance criteria have been met. The report showing completed
user stories/tasks and acceptance criteria will be provided to the customer team.
After the post-sprint customer demo, the software produced during the previous
implementation sprint is ready for testing by the customer team in their test
environment. This is shown in the below example plan highlighted in red:
The customer team should be encouraged to test each of the completed user stories and
tasks as much as possible according to the agreed acceptance criteria. It’s much better to
identify issues as early as possible rather than leaving all testing to the formal UAT activity at
the end of the Engineering phase.
Another major benefit of this early testing activity is business users actually get to see and
touch implemented features for the first time. This is a great opportunity to see if they provide
the expected value and work as expected. If not, they have the opportunity to add, change or
reprioritize requirements planned for upcoming implementation sprints as appropriate
(however not in the middle of an active sprint).
This timely post-sprint customer testing is a critical activity in the Agile PDF, and if it’s not
being managed and completed properly needs to be flagged as a major risk as the project
has been planned assuming testing will occur in parallel to the Engineering phase. If not, it
defers all testing to the end bringing all the issues associated with waterfall-style testing and
creates a strong possibility that the go-live date will be delayed and other negative impacts.
The example plan below shows the hardening sprint highlighted in red:
Note the above activities are all finalization activities. They should have been planned and
started during the implementation sprints so that the hardening sprint is focused on ensuring
these are completed ready for final testing during UAT. This helps ensure UAT runs smoothly
so that UAT is essentially just final confirmation that everything is ready for go-live.
The focus on the non-functional requirement testing typically includes software security
scans, penetration testing, PCI compliance review and other regulatory tests that are
mandated by the project's industry.
The duration of the hardening sprint is typically 1 week, although it depends on the number
and duration of previous implementation sprints, and the amount of software developed. The
above example plan shows a 1-week hardening sprint following five 3-week implementation
sprints.
1. Post-sprint user testing (T0-T5) – This is where the customer’s business users informally test
the user stories and acceptance criteria that were delivered after the previous sprint. This is
sometimes referred to as informal acceptance testing. It’s informal because there is no formal
sign-off.
2. User acceptance testing (UAT) – This is where the customer’s business users formally test
the full delivered solution and acceptance criteria that were delivered after the final hardening
sprint. This is referred to as formal acceptance testing. It’s formal because it results in the
formal acceptance of the delivered solution.
The customer needs to test as early as possible following each sprint. Without thorough post-
sprint testing, issues and functional changes will be identified much later, which will cause
delays and issues during formal UAT, thereby risking the go-live date.
Continuous customer testing is necessary throughout the Engineering Phase and needs to be
planned by the customer from the very start of the project. If the customer does not
thoroughly test, it needs to be flagged as a major project risk because it’s a fundamental
component of the Agile Project Delivery Framework.
Often the customer is not used to such regular testing cycles so post-sprint-testing needs to
be planned with the customer as early as possible to ensure they have resources ready, test
environments, test data, etc.
Early testing by business users during post-sprint testing also allows them to use the solution
properly for the first time, and verify whether the functional requirements work as expected
and provide the expected business value. If not, the flexible scope can be adapted and re-
prioritized in preparation for any yet-to-start implementation sprints.
This early testing also provides confidence to the customer team and builds trust in the Agile
approach of the Agile Project Delivery Framework. It’s amazing to see the positive reaction of
customer business teams that are used to a waterfall process and not seeing anything for
months.
Potential defects need to be reported with a severity rating, sufficiently detailed description
outlining how to reproduce, screenshots, log files, etc. The project team then needs to resolve
critical bugs according to a predefined priority so they can be retested in advance of the
creation of the next implementation sprint package.
It’s recommended there is no formal acceptance or sign-off with post-sprint-testing, due to:
Features are rarely 100% complete at the end of a sprint, as large features are often split into
smaller stories delivered over a series of sprints. This can make sign-off difficult.
Signed-off user stories might be touched again in later sprints, but if they are already signed-
off, then they need to be signed-off again which potentially leads to problems.
Starting the next sprint before sign-off is a risk as fixes/changes will often be required for sign-
off of the previous sprint, but these will be done in parallel to on-going development in next
sprint, and if fixes are not delivered this prevents sign-off. Even low priority defects will need
to be delivered for sign-off regardless of business value, potentially pushing higher value user
stories off the backlog for the next sprint, and possibly even the release.
All these potential interrupts/overhead can create velocity issues with the subsequent on-
going sprint.
There are significant overhead managing acceptance testing dependencies required for sign-
off, e.g. environments, test data, interfaces, etc.
It’s challenging to get customer resource availability for sign-off, often leading to sign-off
delays causing risk to subsequent sprints.
Non-functional requirements are very hard to sign-off by sprint, and can typically only be done
during the formal UAT period once the whole solution is delivered in a proper test
environment with representative data. Ideally functional & non-functional requirements are
signed-off together as they are often related.
User acceptance testing (UAT) is the formal acceptance of the delivered solution, i.e.
testing of the deliverables of the Engineering Phase. It is a period of several weeks
following the hardening sprint during which the customer performs comprehensive
end-to-end testing preferably by the business users who will use the solution after go-
live.
The duration of the UAT period is proportionate to the duration of the implementation sprints,
then adapted for complexity, testing efficiency, and other factors. In the above example, there
are five 3-week implementation sprints and five weeks planned for formal UAT. During the
preceding hardening sprint, the project team has validated that all UAT pre-requisites are
complete and the UAT environments are ready.
The logistics of the UAT period are discussed during the Foundation Phase and documented
in the Quality Assurance Definition, and any contractual specifics of the acceptance process
will be defined in the contract between the customer and the project team organization. It is
valuable for the project team and customer to revisit the planned logistics and discuss the
schedule, meetings, tools, and workflow during the Engineering Phase.
During UAT the customer is testing the solution and reporting issues, then the project team is
determining whether they are defects or scope items, and then prioritizing and fixing defects.
The customer’s business users will have already have tested most features during post-sprint
testing which, if done properly, greatly reduces the amount of effort (and duration) of UAT as
many issues will already have been identified and fixed beforehand.
The UAT period is not for the development of new features. Feature freeze occurs at the end
of the implementation sprints, and this period is too late to create new features without
creating a significant risk to the quality of the solution.
UAT is formal because it results in the formal acceptance of the delivered solution. This
acceptance can either be explicit acceptance (e.g. signed acceptance letter) or implicit
acceptance (e.g. go-live).
However, unlike other activities, formal UAT cannot be time-boxed as it only ends when the
customer has accepted the deliverables, either explicitly or implicitly by going live.
Acceptance cannot be forced if there are significant non-conformance issues related to the
acceptance criteria.
1. A software package is provided by the project team to the customer after the end of the
hardening sprint, together with documented functional/non-functional requirements
and their agreed acceptance criteria.
2. The customer has X days to report non-conformance against these acceptance criteria.
3. The project team has Y days to resolve issues and provide resolutions in another
software package.
4. The customer has Z days to re-test only those reported non-conformance issues and
report further non-conformance against them (this prevents the UAT period being
extended indefinitely).
Then back to step 3 until no further significant non-conformance issues are reported.
Ensure delivered user stories meet the acceptance criteria agreed during the implementation
sprints.
It’s highly recommended to create automated acceptance tests against these acceptance
criteria during the implementation sprints, e.g. make this part of the Definition of Done. This
will greatly decrease the chances of issues being found during by the customer’s business
users during UAT.
Agile Testing:
Ensure interfaces to external systems work as expected and meet acceptance criteria agreed
during implementation sprints.
It’s highly recommended to start this as soon as possible during the implementation sprints.
This requires interface related development to be prioritized accordingly and systems to be
connected in the respective test environments.
Dependent on the readiness of appropriate test environments and representative test data.
This usually requires significant planning which should start as soon as possible.
Performance Testing:
Security Testing:
Warranty
Although not discussed in depth here, it’s important to consider the warranty. Once the
customer has accepted the solution conforms to the acceptance criteria (either explicitly or
implicitly), the solution will often be covered by a warranty period agreed between the
customer and the project team. The duration of this period will vary between projects and will
be defined in any contract between the
parties.
The project team should estimate the effort involved to support the warranty period and factor
this into their project planning from both a cost and resourcing perspective.
Agile PDF - 4. Deployment Phase
One of the key fundamentals of Agile is that software is delivered regularly in an iterative and
incremental manner. This is done by splitting projects into releases and releases into sprints.
It’s also important that each of those deliveries is thoroughly tested as soon as possible,
ideally by real end-users.
Therefore although not mandatory, it’s highly recommended the software developed during
every release is deployed to the live production environment accessible to real end-users
during a Deployment Phase at the end of each release. This will allow the customer and
project team to:
1. Verify functionality, assess real business value, and gather feedback from end-users as
soon as possible so changes can be fed into the planning for the next release. This feedback
will allow the customer to adjust the prioritization of new features according to real feedback,
rather than based on assumptions about what end-users want.
2. Verify non-functional aspects of the software by proving the solution in a real production
environment, e.g. the solution scales as expected, performance meets requirements, caching
strategies work as expected, etc. Testing can only verify so much. Only a real, live production
environment with real end-users will properly verify that the non-functional requirements are
met. Feedback here will also allow for better prioritization in the next release, e.g. the
technical value of a new caching strategy to improve performance might be increased which
makes it higher priority compared with some less valuable functional requirements.
3. Avoid the much riskier “big-bang” approach where software is developed over several
releases but only deployed to live environment after several releases. With big-bang releases,
any issues will be found too late to change, which will have a major impact on users and the
long-term success of the project, e.g. architectural issues are very costly to change later.
The purpose of the Deployment Phase is to support this deployment into the live production
environment and to provide the customer with dedicated post-live support immediately
following the go-live.
Here is a typical high-level project plan showing the Deployment Phase in relation to the
preceding Engineering Phase and the go-live event:
Usually, the Deployment Phase starts a week or two before the planned go-live and continues
for a period of time after go-live for post-live support (sometimes referred to as hyper-care or
similar). Customers are usually very keen to go-live as soon as possible after the software is
acceptance tested at the end of the Engineering Phase. So often the start of the Deployment
Phase will overlap with the end of user acceptance testing.
However sometimes the customer will defer the go-live for a future date, maybe even weeks
or months after user acceptance testing has completed. They might not even know when it
will go-live. For example, this can happen if the software is dependent on another system that
isn’t ready, or if it’s part of a larger program and other project streams aren’t ready. In these
cases, it’s important to plan how a Deployment Phase will be resourced if there is no fixed
date, as the project team might have moved onto another project by then.
Therefore the Deployment Phase is optional and might not be required if:
1. No go-live
2. “Soft-launch” go-live
3. Go-live overlaps subsequent Engineering Phase
Customers may have valid reasons for not deploying a release into the live production
environment or make it available to end-users. For example, re-platform projects can be
relatively large due to the existing platform being developed over many years, and end-users
expect the same current-live features as a minimum go-live requirement. Often these projects
are split into multiple releases (because otherwise, they are too big), and the customer
doesn’t want an earlier release going live with a subset of features, so they want to wait until
it’s fully developed and at least all current features are ready.
In these cases, the customer can often be convinced to go-live with an earlier release using a
limited ‘soft-launch’ approach (see below).
2. “Soft-launch” go-live
A “soft-launch” is where the software is deployed to the live production environment but it’s
only made available to a subset of users. This is opposed to a “hard-launch” which is where
the software is made available to the full user base and any previously existing solution is
switched-off (full cutover).
Therefore, with reduced end-users for soft-launches, the customer might not require
dedicated services to support deployment in a separate Deployment Phase. However, some
kind of similar capacity and specialist resource availability is still highly recommended, even if
part-time.
Sometimes the production go-live can occur during the Engineering Phase of a subsequent
release. In this case, the resources required for the Deployment Phase might already be
available in the Engineering Phase. So the activities of the Deployment Phase still occur, they
are just planned within resources of the Engineering Phase rather than having dedicated
resources provided by a separate Deployment Phase.
However, this requires the go-live to be within the appropriate timescales of the Engineering
Phase. If the go-live date moves then resources might not be available.
It also requires an appropriate capacity to be planned into the Engineering Phase, e.g.
reserving a Story Point buffer. In case this capacity is not needed (e.g. the go-live date moves
outside the Engineering Phase timescales), then this capacity can be used for functional
development or something else. If using the recommended Story Point buffer approach, then
this is easy to manage.
Depending on the project set-up, resources, and customer, sometimes it’s better to separate
Deployment and Engineering Phases (e.g. to ring-fence resources). However other times it’s
better to combine them within the Engineering Phase (e.g. more efficient use of resources).
This depends on the project.
Deployment Activities
The specific activities of the Deployment Phase can vary depending on the project, however,
it’s important to remember that this is not a software development phase. The software will
have been developed and tested in the preceding Engineering Phase. Therefore no new
functional development should be planned during the Deployment Phase, however, capacity
should be reserved for fixing defects that may be found during this time.
Often the customer will push for extra development during this phase to try and squeeze in
some extra features, however this is very high risk and should be strongly resisted as it
creates a major distraction for the project team, they aren’t focusing on Deployment Phase
activities, and these new features will not be properly tested. Together these will very likely
create quality issues, which will cause later problems and negatively impact the success of
the go-live.
Typically the Deployment Phase can be split into two distinct activity groups (activities may
vary depending on the project):
Pre-go-live activities
Final checks of the production infrastructure, operating systems, and applications to ensure
they are properly configured and secure. Also known as production hardening.
Verification of production data. This can include data that’s loaded or migrated from another
system, and data that’s prepared for the live environment, e.g. enriched product data or
content.
Deployment of solution release candidates into the production environment.
Final end-to-end system integration testing to ensure all systems are working properly
together and that the data is making its way through all systems as expected.
Ensure a release management process is in place to handle any critical hotfixes immediately
after go-live.
Back-up/restore processes are in place and tested.
Regular batch processes are properly configured and tested.
Note: some of these pre-go-live activities are only applicable for the initial go-live release.
Post-go-live activities
Resources should be dedicated and made available for ‘post-live support’. This is
supplementary to the customer’s standard 1st/2nd/3rd line support model that should also be in
place with their incident/problem management processes. Post-live support during the
Deployment Phase is provided by members of the project team that are dedicated and
assigned specifically to support the standard support team in a hyper-care model, i.e. to
provide deep expert knowledge and fast responses to incidents.
Having members of the project team dedicated during post-live support is an insurance policy
for the customer. They are there to ensure smooth running during this most critical time after
go-live. Standard support teams typically work to defined SLAs, however, the post-live
support team provided during the Deployment Phase are there to work as quickly and
efficiently as possible to resolve/workaround all issues without requiring the delay and
overhead of escalations via the 1st/2nd support lines.
Typical issues tackled during post-live support can be environmental, operational, data or
performance related. These can be complex issues that might take the standard support team
a lot longer to investigate/resolve. See Issue Reporting and Escalation Recommended
Practices - Recommended Practice.
Resources need to be planned ahead of time to be available as appropriate, e.g. 24/7 if
required. See After Hours Support Recommended Practices - Recommended Practices
There are no deliverables for the Deployment Phase. The phase finishes when the post-live
support is ended. From this point, all support issues are handled by the customer’s standard
1st/2nd/3rd line support model. A proper hand-off between the project team and the support
team will ensure a smooth transition of the on-going operation. See Application Management
Hand-off Checklist Recommended Practices.
Cutover planning needs to start from the very beginning of the project during the project
Initiation
Essentially, cutover planning, preparation, and execution run the entire duration of a release.
However, there are two distinct types of activities to plan:
1. Preparation activities – these need to be completed before a go-live decision can be made,
i.e., incomplete activities may prevent go-live.
2. Execution activities – these are completed around the go-live event itself once all
preparation is complete and the go-live decision has been confirmed.
Cutover preparation activities will vary depending on the specific context of a particular
project. However typical preparation activities include:
The cutover strategy must be agreed with all parties right from the start of the project during
the Initiation Phase, as it will have a direct impact on the release roadmap, timelines,
resources, prioritization, and many other important decisions.
Time constraints: e.g., any IT or business blackout period when no cutover activity should be
planned, e.g., during a key sales period.
Soft launch vs hard launch: Promote the idea of frequent releases. If a “big-bang” approach is
taken, the planning should consider the risks associated.
System dependencies: Call out any dependencies with other on-going & dependent
integration projects.
Legacy system: If the solution is to replace a legacy system, the cutover strategy needs to
include the migration or conversion steps from business, technical and data perspectives to
ensure minimal impact and risk.
Resources outside of the project team may be involved in go-live activities. The resource
requirements and availability need to be confirmed during the Engineering Phase. In some
cases, go-live execution activities will occur outside office hours which need to be factored in
the resource plan.
The deployment team organization needs to be planned and shared with contact information.
The decision maker and escalation path need to be in place in case an emergency or if an
unforeseen situation is encountered during go-live.
Business Preparation
Change management is an important part of cutover planning. The customer needs to define
a strategy that will enable acceptance and deliver the expected business value of the new
solution. The amount of change management required varies by organization. It can involve
tasks such as promoting new processes and functionalities, a communication strategy and
enabling end users via training.
End-user training is designed for business users and administrators to enable them to
perform their responsibilities based on the implemented solution and workflow processes.
This is different to standard Hybris Commerce product training that is training based on the
core underlying Hybris Commerce product, on top of which the customer’s solution has been
implemented. During the Foundation Phase, the end-user training needs are discussed so
that material preparation and training delivery are scheduled appropriately.
Typical end-users include:
Content managers for managing web content, page layouts, images, etc.
Product managers for managing products, catalogs, prices, product content, etc.
Customer service agents for assisting customers with orders, payments, site usage, etc.
Administrators for managing the solution itself, e.g., users, groups, passwords, structures, etc.
The project team typically provides end-user training as they have the best knowledge of the
implemented solution. This training can be provided as classroom or train-the-trainer sessions
depending on the needs of the customer. If train-the-trainer then one or more customer
trainers will be enabled by the project team so that these customer trainers can train the other
business end-users.
In either case, ideally, the training contains a large portion of practical exercises that need to
be prepared up front. Training sessions are highly dependent on an appropriate and stable
training environment and representative data. This needs careful upfront planning. Otherwise,
environment and data issues can cause significant disruption and frustration during the
training.
Technical Preparation
The go-live checklist covers all the technical steps that are required to take during
deployment. At a high level, the hosting infrastructure needs to be planned during the
Initiation Phase. The provisioning of the development and test environments is planned during
the Foundation Phase. Production hardening and readiness are planned during the
Engineering Phase.
Documentation
Documentation needs might include user manuals, help guides, administration guides,
deployment guides and training materials. These documentation requirements need to be
identified during the Foundation Phase, then appropriate effort, preparation, and completion
of the documentation are planned accordingly during the Engineering Phase.
Transition Plan
Transition refers to the hand-over of the solution for long-term application management or
development after go-live. This long-term model should be agreed upfront during the Initiation
Phase so it can be incorporated into the project planning. Hand-over topics will typically
include:
It is very costly to have any problem during deployment that causes interruptions in the
production site. It is, therefore, essential to have a backup and restore process in place to
recover from potentially failed deployments. These processes should be defined during the
Engineering Phase and tested as early as possible to allow enough time to correct any issues
and re-test.
Batch Process
Batch processing represents any set of automated tasks (jobs) that are executed without user
intervention. In the context of a Hybris Commerce system, batch processing includes
CronJobs, Impex Jobs and any integration process such as those which transmit data to or
from Hybris Commerce and ERP or other master data repositories, order processing, pricing,
inventory, and business intelligence or reporting. Batch processing can also include system
maintenance routines such as data backup and cleanup.
These processes should be defined as requirements during the Foundation Phase, then
designed/built/tested during the Engineering Phase.
Data Readiness
Even with the best designed, developed and tested solution, if the underlying data is poor
quality it can have a major impact on the solution functionality, performance and general
behavior of your solution, potentially causing a significant amount of user frustration and
issues.
The common examples of key data include customers, employees, orders/carts, promotion
and CMS content & media.
Data Migration – The data migration requirements should be defined during Foundation
Phase. This strategy covers how to migrate data from other systems into SAP Hybris
Commerce, perhaps from an existing solution being replaced. It also needs to consider
changes to the data model. Data migration often requires the development of ETL-type
processes during the Engineering Phase which needs up-front planning. It is also important to
consider data protection issues when working with real customer data. These are the
common scenarios of data migration:
Getting existing data from an existing system into a new SAP Hybris Commerce
implementation (see Data Migration)
Moving data from one database to another (see Data Migration)
Moving data between SAP Hybris Commerce environments (see Data Migration and Options
for Refreshing CMS Content Between Environments )
Data Creation – During the early implementation sprints, there is typically a lot of changes to
the data model requiring the Hybris Commerce system to be reinitialized with each sprint
deployment, which clears the database of all structures and data. At some point, the project
team needs to stop re-initializing the system with each sprint deployment so that data can be
loaded, enriched and persisted between deployments in preparation for testing and go-live
(e.g. product and content data). This needs to be planned ahead of time and often has data
and resource dependencies.
Data Cleansing - Imported data often comes from a variety of different sources, with
questionable data quality. For example, properly working faceted search and navigation is
100% dependent on high-quality data on which the search indexes are built. If there’s a color
facet and there’s a ‘green’ and ‘greenn’ (misspelled) value, there will be two values shown
instead of one or the ‘green’ value is used, and it misses the product with the misspelled
value. The quality of source data needs to be assessed from the start of the project during the
Foundation Phase and appropriate time and resources planned to ensure it’s corrected before
being imported for go-live.
Go-live Checklist
A go-live checklist is essential to ensure that no steps are missed during deployment to the
live production environment. This checklist should contain task descriptions, dependencies,
owner, and status. The checklist is defined during the Engineering Phase, and will be
reviewed with the team during the Deployment Phase. See the sample go-live checklist Excel
document attached to the Infrastructure Considerations for more details.
Cut-over execution activities are completed around the go-live event itself once all preparation
is complete and the go-live decision has been confirmed. These will generally consist of:
1. Preparation tasks leading up to go-live day, e.g., validating the go-live checklist, final testing
of system integration points, etc.
2. Preliminary tasks on go-live day, e.g., stopping transactions to the solution being replaced
3. Go-live activities, e.g., removing holding page
4. Immediate post-live activities, e.g., end-to-end testing transactions, monitoring system
resources, etc.
5. Activities following go-live day, e.g., continuous monitoring of transactions, system resources,
responding and resolving post-live issues as quickly as possible
Fundamentals
One key feature of this approach is that it places emphasis on documentation such as
Functional, non-Functional and Technical Design documentation. It provides a structured
approach; the model itself, like Agile, progresses linearly through discrete, easily
understandable and explainable phases; it also provides easily identifiable milestones during
the development process.
The Engineering Phase tends to be shorter than with the Agile approach. This is because
more time has been invested ‘up front’ to define the requirements in detail. Thus, less design
is being done as the code is built. Another feature of this methodology (although this is not
mandatory) is that code is not handed over to the customer for testing until near, or at the end
of the Engineering Phase. This is done to a certain extent to try and minimize changes from
the customer, but also to allow more focus on the build without the distraction of continuous
customer integration, customer showcases, and early customer test result analysis.
Finally, the Deployment Phase tends to be longer for the reasons mentioned above. More of
the testing and defect fixing is moved into that phase, along with the other pre-go-live
activities like training, data verification, system integration testing, etc.
Assumptions
The Iterative Framework does adopt some practices associated with Agile (in particular during
the Engineering Phase) such as Sprints, Daily stand-ups, Retrospectives, etc. It also tends to
talk in a development currency of Person Days as opposed to Story Points (although either
currency can be used in either methodology). This is not mandatory, but Person Days are
more commonly used for Waterfall projects. Also, the Iterative approach talks about a single
Engineering Phase with a release at the end (following the Deployment Phase). Agile tends to
break the project down into ‘releases’ which are in themselves almost mini-projects with a
short Foundation Phase at the beginning and Deployment Phase at the end rather than a
single Foundation – Engineering – Deployment flow. Again, this is not mandatory, and a
project can easily be broken into ‘releases’ using the Iterative methodology.
Some argue that a more Iterative model is most suitable for smaller projects where
requirements and scope are fixed, the product itself is firm and stable, and the technology is
understood. It is also well suited to a ‘time and materials’ contract model, and to customers
who are keen to have requirements signed off early so that there is less ambiguity when it
comes to verifying/testing the result.
One disadvantage of Iterative Methodology we describe here is that it does not allow for much
reflection or revision. Once an application is in the testing stage, it is very difficult to go back
and change something that was not considered at the concept stage. Any required changes
must be subject to an agreed and rigorous Change Control Process. Major changes that
increase complexity or functionality (features or functionality are seldom removed to
compensate for increases) are likely to result in an increase in time, cost or most likely, both.
Phases
Phases Summary
Initiation The Initiation Phase is the first part of the discovery and planning activity of a
new project. Its primary objective is high-level alignment between the
Phases Summary
Foundation The primary objective of the Foundation Phase is to establish foundations for
the project from business, technical and project management perspectives.
This involves establishing an understanding of the business requirements for
the project, agreeing on the approach, and determining how development and
implementation will be managed from technical and project management
perspectives
Engineering The idea of the Engineering Phase is to build software to meet the functional
and non-functional requirements signed off in the Foundation Phase.
Deployment The primary objective of the Deployment Phase is the successful deployment
of the solution delivered by the preceding Engineering Phase into a
production environment so it’s accessible to end users. This phase includes
the provision of immediate post-live support to ensure stability and fast
resolution times in case of any issues.
Below is an example project plan for an Iterative PDF initial implementation project:
The duration of the phases can vary however this is a very typical plan.
Key points from this example plan:
The Initiation Phase isn't shown as typically this is either an in-house feasibility study or pre-
sales phase for an external services provider, so at this point, the project hasn't formally
started. One of the objectives of the Initiation Phase is to create this initial high-level project
plan.
The Foundation Phase is longer than in the Agile PDF as it includes the signing off of
all documentation. The whole phase is not carried out on the client site (in this example the
first 6 weeks would probably be on the client site). Any proof-of-concept (if needed) will be
done during this phase to ensure requirements are fully defined before Engineering begins.
User Acceptance Testing (UAT) is normally done during the Deployment Phase, although on
larger builds completed functionality can be released for testing before the end of
the Engineering Phase to allow the customer to get a head-start on testing.
In the Deployment Phase, Production readiness activities can start before acceptance testing
is finished.
Go-live is at the end of UAT, with some of the Deployment Phase activity being immediate
post-live support. This is not the same as regular support provided by
Application Management as post-live support (not shown on this plan) is usually delivered by
the Engineering team in conjunction with Application Management during this critical post-live
time period.
Application Management starts ramping up and preparing during the preceding Deployment
Phase, e.g. support engineers working as part of the development team to gain knowledge
and experience.
The Iterative principles are listed below, and many of these are common to both Iterative and
Agile.
Fixed scope
Time-boxing
Iterative development (sprints)
Fully defined and signed off scope prior to Engineering
Acceptance criteria
Rigorous change control
Quality baked-in
Empowered customer representatives
Cross-functional collaboration
Continuous improvement
Creative design
Transparent reporting
Contracting model (if appropriate)
Fixed Scope
During the Foundation Phase, the information gathering process is very rigorous. All
requirements are documented in detail via the use of annotated wireframes (to bring the
solution alive for the customer who may otherwise have problems picturing what they will
actually get), Functional and Technical Specifications, user journeys and (if time permits)
Tasks/User Stories. All functional flows are documented and detailed technical documentation
showing all interfaces/integrations to 3rd party systems are produced. Detailed specification
documents covering all functional and non-functional areas are signed off prior to the
Engineering Phase commencing. The full Engineering and Deployment Phases are then
planned (in relative detail) with the assumption that no changes will be made to the
requirements.
Time-Boxing
It is good practice within any project delivery methodology for everything to be time-boxed so
it has a fixed start and end time. This includes phases, sprints and even meetings. This time-
boxing ensures time control is baked into everyone’s mindset from day one, and it’s important
that nothing is allowed to extend outside its time frame. Ultimately this naturally ensures all
the project activities are delivered on-time, and therefore increases the likelihood the project
as a whole.
By time-boxing regular events, people get used to the rhythm, which makes them optimize
their time to suit, which then leads to the more focused use of time and less wasted time.
Each sprint consists of review/build/test which are typically performed in multiple parallel
analysis/design/build/test activities for each requirement. By empowering the team, have
them commit to a sprint goal, then allow them to self-organize to meet that goal, whilst
providing guidance and proactively removing impediments, it allows them to organize these
activities to maximize efficiency.
Sprints are optional in the Iterative PDF but are recommended as they make pre-planning,
progress management and code/process review easier as this is done on a smaller, iterative
scale rather than being left until the end of a long Engineering
Time Contingency
With fixed scope projects it is important to ensure time contingency is built into the plan, in
particular around the Engineering and Deployment Phases. In any project, there are
unforeseen factors that could impact the delivery plan. This includes the unplanned absence
of a key individual or individuals, a particularly difficult and unforeseen technical challenge,
slow responses from 3rd parties etc. Many of these challenges can be mitigated by building
extra time into the plan. This can be done in several ways:
Contingency should not be hidden from the customer, and its importance explained to them.
Often this is an area that a customer will try to remove or cut in order to save time and cost
but this should be discouraged.
Cost Contingency
Cost contingency is normally more difficult to get a customer to agree to. It may come in the
form of having to replace a cheaper (junior) developer with a more expensive (senior)
developer if development is not proceeding as quickly as planned. Alternatively taking on
additional people to mitigate time slippage. Getting the customer to agree to pay cost
contingency up front is difficult even if you are open and honest about its need.
Acceptance Criteria
Acceptance criteria are specified for both functional and non-functional requirements. These
are agreed and signed off by the customer. Both the functional and non-functional acceptance
criteria are defined and signed off during the Foundation Phase, then amended via change
control during the Engineering Phase if needed.
Test automation is then created around these criteria. The functional tests are done sprint-to-
sprint as they are developed, and non-functional tests as appropriate. Having a high level of
automated coverage allows the testing teams to focus only on new requirements in each
sprint and not spend wasted time with continuous manual regression testing, as the
automation tests should pick up regression issues. Thorough test automation also gives a
very high level of confidence when entering user acceptance testing at the end of the
Engineering Phase. These acceptance criteria are then used as the basis for the customer’s
user acceptance testing.
All testing activities must be identified from the start, responsibilities assigned, and planned
alongside all other critical path activities. These will cover all aspects of testing including
functional, non-functional, exploratory, system integration, cross-browser, and cross-device
testing.
Testing should never be left to only the customer, and should never be left to only the
developers. Dedicated and professional testers are an essential part of the project team and
need to work alongside the developers, ensuring quality throughout and at every stage of the
project lifecycle. Every delivery to the customer must be properly tested beforehand to
minimize defects and wasted cycles investigating/fixing defects and re-delivering for repeated
customer testing, all of which is a huge source of wasted time and effort.
Investing in dedicated testers within the project team will easily pay off over the course of the
project and it’s vital they are planned from the start. They are a key part of the project team.
Cross-Functional Collaboration
Iterative PDF encourages cross-functional collaboration through four streams: project
management, business, technical and quality management. Each of these streams has a
corresponding owner on the project team and the customer side. This improves
communication with the customer and underlines the importance of each of these
perspectives.
Continuous improvement
Continuous improvement isn’t specific to Iterative PDF, however, it’s a cornerstone of the
efficient and effective workings of the project team. There are regular meetings (called
retrospectives) to discuss what was good, bad and can be improved at specific points in the
project. Actions are taken for the most valuable areas of improvement, they are implemented
and monitored, then reviewed again to check they were effective. Then the next most
valuable areas are tackled, and so on.
Retrospectives are a vital part of workings of the Iterative PDF project and occur at the end of
every sprint and at the end of the project. This process of continuous improvement becomes
embedded in the mindsets of the whole project team, which not only improves ways of
working but is also very motivational as it empowers the team to make positive change.
Creative Design
Often there is a separate organization or design team responsible for designing and creating
the user experience and creative designs for the user interfaces, then the project team is
responsible for taking these designs and integrating them with the back-end development to
meet the overall requirements.
In these cases, it’s essential the three key parties (customer, design team and project team)
collaborate from the start and throughout the project. There are tight dependencies between
the designs and the implementation, along with trade-offs in terms of features and effort.
Transparent Reporting
Iterative PDF using Sprints allows visible and transparent progress reporting. Real-time
progress is made visible using burndown charts (a Scrum concept) during each sprint so the
project team and stakeholders can see if the sprint target is going to be achieved. There is
also an Engineering Phase is on track. If it looks likes targets are not going to be met, early
action can be taken. The full burndown chart will also highlight any agreed changes
(additional functionality) introduced during the Engineering Phase and the impact it has on the
delivery dates,
It is essential these real-time progress reports are shared with the customer, and the
customer is educated so they can fully understand them. This builds trust from the start and
avoids surprises later. If something is going off track early, it is far better to tackle this
together with the customer at the first signs, than hiding and hoping it improves. Trust is an
essential part of the collaborative working and therefore the success of the project. As soon
as the customer thinks something is being hidden, trust is damaged and it is very hard to
repair it. Far better to talk about issues up-front and tackle them together in partnership whilst
working towards the shared goals and objectives of the project.
Given that things are likely to change, the alternative is to agree on an effective Change
Control process with the flexibility to take each change as it appears, and give a time and cost
against it that the customer then agrees to pay or not (in which case the work is not done).
The cost of reviewing and estimating new changes must also be factored into the time/cost
calculations. as this is something the client should not expect for free.
With fixed price, much more attention needs to be focused on those fixed scope requirements
at the start of the project to mitigate risk, so they must be documented in much more depth
with a formalized sign-off and rigorous Change Control process which is why the Foundation
Phase is longer with the Iterative methodology.
The Time and Materials (T&M) cost model can very easily be used for the Iterative PDF. Of
course, a T&M approach requires greater trust, and this is supported by transparent progress
reporting. This approach can be mitigated by ‘milestone payments’. This is where the
Customer makes regular payments during the life of the project once agreed milestones have
been reached.
Another option is using a capped T&M approach with contracted deliverables and milestones,
and where the cost will not be exceeded without a formal change request allows both time
and cost to be controlled. This is another option which gives more confidence to the customer
and keeps teams focused on these two critical components.
Functional Requirements
During the Foundation Phase, both Functional and non-Functional requirements are drawn up
in detail. This may include the use of annotated wireframes that bring the functional solution
to life for the customer. It is imperative that the customer understands what they are getting,
as changes are to be discouraged once the Engineering Phase starts. Sign off can be done
via one single, large document, or smaller documents covering off functional areas, but it is
imperative that all documents are understood and signed off before the start of Engineering.
Features, Sub-Features, User Stories and Technical Tasks
As with Agile, Functional requirements are initially documented as high-level ‘features,' then
progressively refined into ‘sub-features,' and then ‘user stories’ and ‘technical tasks.'
Acceptance criteria are then defined against Tasks or User Stories. Where this differs from
Agile is that the refinement is done at an earlier stage.
Features are initially identified in the Initiation Phase. These are high-level and allow rough
sizing and prioritization to create a high-level Project Plan. Then, during the Foundation
Phase, the features are re-evaluated and broken down into finer-grained sub-features. Sub-
features and the associated features are documented and planned into the Sprints within the
Engineering Phase, and the sub-features are broken down into tasks/user stories, and
technical tasks and their acceptance criteria are defined and agreed with the customer.
During Engineering the tasks are reviewed again during the Sprint pre-planning before the
Sprint in which they will be developed, but at this point – because the task has already been
well defined - estimates should seldom change.
Once the task has been picked up by a developer, the user stories are further decomposed
into user-story sub-tasks and technical tasks into technical sub-tasks. These sub-tasks
represent activities that will be done during the sprint and are documented using an
issue/project management tracking tool, such as Jira.
Person-Days
Person-days are a standard and simple way of defining the effort required to complete a task.
However, when it comes to estimating a development task in person-days, it is important to
take into consideration the different capabilities of Developers and Testers. A task that might
take one developer three days may take another six days. It is also important to consider that
– as a rule during the Engineering Phase – the general momentum of the team will start
relatively slowly, and gradually increase as people ‘warm up’. Therefore, during planning, this
should be taken into consideration.
Also, a person-day used for estimation purposes should take into consideration the average
productive time a developer/tester will be able to spend developing/testing code as opposed
to being in meetings/training, etc.
Estimation
Person-days are used to estimate features, sub-features, user stories and technical tasks.
During the Foundation Phase, the high-level estimates done during Initiation are reviewed
and fine-tuned. It is crucial that these estimates are as accurate as possible based on the
comprehensive information gathered during Foundation as these form the project baseline.
In Engineering, when splitting features into sub-features, the sub-features are estimated, with
the total size equalling the feature size. The same goes for splitting sub-features into
tasks/user stories and technical tasks. When user stories and technical tasks are split into
sub-tasks, these sub-tasks are not estimated, as they can easily have 10 or more sub-tasks
and splitting the person-days amongst the sub-tasks would be too much administrative
overhead and the risk that the total of all sub-tasks does not equal the parent would be too
high.
Velocity
Velocity is the total number of person-days capable of being delivered during a sprint. This is
a key metric because it is used to predict how long it will take to complete the build and
therefore the length of the Engineering Phase (e.g. if the total build time is 24 weeks and each
Sprint is three weeks then the velocity needs to be calculated for 8 Sprints).
Therefore it’s important to be able to accurately predict the velocity of a team. If using the
same team and they have already delivered previous, similar projects you can use the team's
historical velocity and start from there,
However, for teams who are new or inexperienced in any of the areas you will be working on,
you can only estimate the velocity. For that, you need to calculate the team’s productivity as
the starting point. An individual’s productivity can be calculated through:
Availability
Experience level
Skill-set
As a general rule, the velocity will increase during the Engineering Phase as the team gel and
gain experience/confidence in the technology and subject matter. So, for example, an
individual’s productivity may start at 60% in Sprint 1, but have increased to 100% or even
110% (if the individual is over-achieving on their Sprint goal) by Sprint 8.
In an Iterative project, the customer need not be so concerned about individual Sprint velocity
provided the end goal is successfully reached. For example, if (to make things simple) each of
the 8 Sprints had an estimated velocity of 50 person-days this would give a total Engineering
goal of 400 person-days. Perhaps by Sprint 3 a velocity of only 145 person-days (5 days
deficit) has been reached, but this is fine as long as those days are made up by the end of
Sprint 8. The supplier PM should be open and honest during their reporting throughout the
Engineering Phase on any shortfall, reassuring the customer that this can be made up, or
putting in contingency measures (perhaps substituting a junior developer with a more senior
developer) if this does become a project risk.
Non-Functional Requirements
As with the Functional requirements, these must always be fully elaborated and signed-off up-
front during the Foundation Phase together with their acceptance criteria, then only changed if
required during the Engineering Phase using a rigorous Change Control process. This is
because, like Functional requirements, NFRs need to be fully known up-front before
Engineering starts as they have an immediate and direct impact on the solution architecture
and design, which are tough and expensive to change later.
For example, there is a very significant difference between a system that needs to support 10-
page impressions per second (pi/s) vs. 100pi/s. Not only will this impact software architecture,
but also the production infrastructure, which will also have a significant impact on the overall
cost. All of which must be identified and known by the end of the Foundation Phase.
The goal of the Initiation Phase is for the customer and project team to explore and agree on
a high-level common understanding of:
Together these will give the customer enough information to decide whether to invest in the
next phase of the project, i.e. the Foundation Phase, which will explore these topics in depth.
Or maybe the customer decides to not continue with the project at this stage. It’s much better
to discover this earlier rather than later when significant effort and resources have already
been committed.
Typically, the Initiation Phase starts with the first discussions between the customer and
members of the project team and concludes when the Foundation Phase begins. It could last
weeks or months, depending on the readiness, the availability and the timeline of both the
customer and the project team. Usually, the Initiation Phase only occurs once in the lifespan
of a single project when the customer is assessing whether to proceed with the project.
From the Iterative PDF perspective, the key to this phase is introducing the fundamentals and
core practices and establishing whether the customer accepts that the project is driven
primarily to control time, quality and cost, and that scope and cost are fixed. If the customer
does not accept this approach, then Iterative PDF is probably not the appropriate delivery
approach for this project and another approach will need to be decided.
Qualification
The purpose of qualification is to determine if the project, the customer, and the project team
are positioned for success.
Iterative PDF - Initiation Qualification
Workshop
Once the customer project has been qualified, it’s recommended to have an Initiation phase
workshop on the customer’s premises to discuss and explore the
why/what/how/when/cost/risks of the project, with particular focus on the initial high-level
functional and non-functional requirements that will be used for a high-level estimate and an
understanding of the project scope.
Planning
Once the Initiation phase workshops are complete, the project team should have enough
information to plan the project, estimate the effort and provide high-level plans and costs. The
objective at the end of this planning activity is to have a common understanding with the
customer on the why/what/how/when/cost/risks of the project, so that the customer can make
an informed decision whether to proceed with the project and the subsequent Foundation
phase or not.
Often qualification occurs during the software license sales process, for example, during the
customer's vendor selection process. Sometimes it's afterward, for example, the customer
has already selected Hybris Commerce as the software platform, and now they need to
decide how to implement it. Here we are assuming this is a new customer and with their first
implementation project, although many of these topics will be applicable in other cases.
It is important that whoever is responsible for the project delivery is involved in this
qualification, working directly with sales or other involved teams. Often there is a history of
important topics from the early sales process, so it's also essential that sales are involved at
every step, at least until the first Engineering Phase kicks off, that is when the customer has
committed to the project.
Naturally, the sales team tend to be more optimistic regarding complexity and delivery,
whereas the project team tends to be more conservative. That's a key reason why the project
team needs to be directly involved in qualification, working closely with the sales team who
may already have set expectations with the customer regarding implementation dates, effort,
duration, and costs. If the project team gets involved too late in the process, it will be much
more challenging to reset any expectations. It's best to be realistic from the start.
The duration of this phase is variable from weeks to months since there is a limited level of
commitment from both parties as a contract has not yet been signed yet and there are many
internal and external factors and dependencies that can impact the process.
Qualification Activities
Often the sales team are the first contact point if it’s a new customer, or maybe someone else
from an account or customer management team if an existing customer.
They will have background information and very high-level information such as timescales,
business goals, rough project size/budget, challenges, etc.
These internal discussions allow very quick assessment whether it’s viable to engage or
whether an alternative option is more suitable.
Customer Alignment
After internal alignment, an initial high-level meeting should be arranged to allow the customer
and the project team to discuss and explore the why/what/how/when of the project.
This allows a quick assessment on both sides whether it’s viable to continue. It also gives the
project team an opportunity to provide feedback to the customer on areas they might need to
think more about before continuing with next steps.
Ballpark Estimate
The customer might want a clearer idea of how much the project will cost as part of the
qualification process and before proceeding further with the Initiation Phase.
This will be a very high-level estimate and is usually based on a requirements spreadsheet
provided by the customer, with some quick question-and-answer sessions to clarify
requirements with the customer.
This won’t be exact, but a ‘ball-park’ estimate expressed as a range using low/medium/high
estimates. Assumptions should also be documented together with the estimates.
This step is optional, as it’s challenging to reliably and accurately estimate a project in this
manner due to lack of information, and the range can be very wide, especially with all the
assumptions. It’s usually much more efficient and valuable to use these requirements as the
base for the following Initiation Phase workshop after qualification so that the customer can
explain each requirement in more depth and the project team can suggest alternative options
that the customer might not have considered. This usually produces a much more valuable
and accurate estimate.
Qualification Topics
Project Goals
Iterative Methodology
Determine which is the best methodology to meet the needs of the customer (Agile or
Iterative)
Determine how the customer’s internal decision making works. Are they top-down or do they
empower people? Are they a collaborative and dynamic organization or do all decisions need
to be approved at C-level?
If the customer is traditionally a Waterfall organization, it might be inadvisable to get them to
work in any other methodology. Even if they are initially willing, they may not be able to adapt
to anything else, and this may put the project at risk.
The amount of time expected from empowered customer representatives is significant. Will
the customer be able to provide single individuals responsibility for the business, technical or
project management decisions? Can they do this in addition to their "regular" job or can they
provide people full-time on the project?
B2B/B2C/PCM
Understand the type of project and type of customer, e.g. business-to-business (B2B),
business-to-customer (B2C), product content management (PCM), etc.
If it's a B2B business, they will be less demanding regarding fancy features, but will perhaps
need more hand-holding regarding eCommerce best practice, so might need more
consulting/coaching. These customers often have less demanding non-functional
requirements as they tend to have fewer users, but greater order sizes.
If it's a B2C business they will probably be more demanding regarding features, but maybe
too demanding and want to push the boundaries of the Hybris Commerce platform,
sometimes beyond its capabilities. They might also have more demanding non-functional
requirements.
If it's a pure PCM project, then there's unlikely to be much front-end work, and more
system/data integration. PCM projects can also be much more Cockpit-focused (Cockpits are
the Hybris Commerce business user applications), so it's good to know how much
customization is likely in this area as it could become complex if non-standard. There will also
likely be an existing eCommerce solution that could be a competitor to Hybris Commerce. If
so, this could create some concerns in the existing eCommerce team that need to be
managed.
Accelerator
Understand if expectations around ‘Accelerator’ have already been set with the customer. If
it's been described as “an Accelerator project,” this sometimes means the customer expects a
lot of their requirements are already met out-of-the-box with just some minor
development/configuration effort before any proper analysis has been completed.
Check if the customer has any other major projects running concurrently.
If there are two major dependent systems being developed in parallel, this can create a lot of
challenges, both from project management and technical perspectives.
From a project management perspective, it will be very important to manage the program
dependencies and risks. E.g. if there's a delay to one project it can have a major impact on
the second.
From a technical perspective, the system interfaces can become a moving target and cause a
significant amount of rework. E.g. if Hybris Commerce is taking a product feed from another
system and the other system is regularly changing the product attributes or structure, this can
have a big impact, not only for the interfaces but also the data model, service layer, and
everything else that sits on top of the data model in Hybris Commerce.
Timescales
Understand when the customer wants to start the project and when they need it to go live,
and what they mean by ‘start’ and ‘live.' Is 'start' the Foundation or Engineering Phase start
date? Is 'live' the hard or soft launch date (e.g. full production or limited friends and family)?
Or maybe there's a global rollout and associated live dates?
Understand what can potentially impact those dates, and whether they are fixed or likely to
move.
Check if the customer has any other timescales constraints that might impact the project, e.g.
strict production deployment windows. This can have a major impact on project planning.
Timescales are critical when managing capacity; there is no point engaging with a customer if
they need to start before the project team can engage.
Similarly, if the start date is long into the future and the project team is ready now, then the
risk of having a team on the bench needs to be managed.
Also, need to assess whether the dates are realistic.
Project Size/Complexity
Understand who will be responsible for the long-term development, support and operations
after the initial implementation project. This can have a major influence on the project
planning, dependencies, and risks.
If the customer takes long-term responsibility in-house, understand how this might impact the
team structure as these resources will need to be part of the project team. Also, need to
assess whether it's realistic for the customer to take it in-house. E.g. whether they are set-up
organizationally, have the right skills and experience, etc.
If responsibility is external, need to find out who will be providing these services and exactly
what services have been agreed. If a partner is involved, then need to understand how this
will work, who has accountability, how this works contractually, etc.
If part of the project team’s organization, need to identify other teams involved and ensure
they are involved in the initial planning as the customer will expect a ‘single face’ and may
expect the collaboration to be factored in automatically.
Partners
Understand the customer’s partner situation. If partners have previously been involved but not
anymore, understand their role and why are they not involved now. Or maybe a partner (or
several) are currently involved in which case need to understand their roles, how they work
together and their goals.
If partners have already been involved but not anymore, find out what they've already
delivered. Sometimes this can be leveraged; sometimes it can create additional challenges.
E.g. if they've already completed some development and charged the customer, the customer
may expect this to be reused regardless of quality.
Sometimes the customer has an incumbent partner in other parts of their business; maybe
this partner wants to get involved.
It's critical to understand the dynamics where there are multiple partners involved. The more
partners involved, the more complex the project can become. It’s very important the customer
and partners establish ways of working with aligned goals.
Hosting/Managed Services
Understand who will be providing hosting or managed services, i.e. who is responsible for the
production and other environments. Is this the customer? An external hosting company?
Don't underestimate the potential impact a poorly managed hosting set-up can have on a
project.
If provided by the customer, this can potentially become expensive for them, have long lead
times and questionable competence of their team and availability.
If provided by an external hosting company, has the customer already selected and
contracted the provider? If not, then this can impact environment preparation lead times and
potentially delay Engineering start dates. If they have, then the environments might already
be scoped and cost, in which case need to check they are correct otherwise it can have a
significant and unexpected impact on costs and lead times.
Regardless of who is providing the hosting/managed services, it's very important to
understand the services included. E.g. does it include deployments? How much access to the
environments will the project team have? These can have a significant impact on productivity
and the services required from the project team and therefore to include in the effort/costs
estimates.
Contracts
It's very important to understand the required contractual base for the project, e.g. fixed price
vs. T&M, and any other previously agreed on terms and conditions.
With the Iterative PDF either fixed price or T&M can be used. However, with fixed-price, a
robust Change Control system which includes time/cost calculations must be in place. It also
necessitates greater up-front requirements/design as the project team tries to understand all
risks and requirements before committing.
Location
Understand where the customer is located and where the project team will be located.
If the customer is distributed, then understand where their project teams are located and how
workable this is. If the project team is working closely with the customer IT team, but the
customer IT team is on the other side of the world and their business team in a completely
different location, this could become challenging for a highly collaborative project. It is less of
a challenge using an Iterative approach during the Engineering Phase as there is lesser
contact with the customer.
Check to see if there are any time zone or other location challenges, e.g. perhaps it's very
difficult to travel to the customer or there are travel restrictions for key people in the project
team.
It is important to know where customer or partner resources which are part of the project are
located. E.g. if there are offshore development resources, this needs to be carefully factored
into the planning as it may have an impact on delivery times.
Language
Understand the preferred language of everyone working on the project, and whether there is
a common language that everyone can speak well.
Also, understand if the documentation is written in the same or different language.
This can have a major impact if people cannot easily communicate both verbally or through
writing.
Culture
Consider the cultures of the people involved in the project and how this might impact the
project methodology used.
For example, in some cultures, it's rude to disagree with someone publicly, so workshops
need to be managed very carefully to ensure people can get their views across.
Remote delivery
Understand if the customer expects or needs an onsite presence or whether they are happy
to work with a remote delivery team.
If the customer needs a lot of onsite support, then need to assess how this will work from
travel perspective based on their location.
If the customer is happy to work with a remote delivery team, then need to assess how well
they can work in this style and whether it's a style they are experienced with. E.g. if customers
are not able to work efficiently and collaboratively with electronic communication tools, this
will quickly become a problem for a project team that's dependent on this form of
communication.
Regulatory Constraints
Check to see if the customer is subject to any regulatory constraints as this can have a
significant impact on a project.
For example, if the customer requires SOX compliance, then they will have much more rigid
documentation requirements and auditing processes that can significantly increase effort and
reduce velocity.
If they operate in an industry that requires signed-off functional requirements and design
specifications, such as the pharmaceutical industry, then the Iterative approach – which
mandates sign off before commencement of Engineering - may be the only option
Licensing
It’s important to understand what the customer has licensed with regards Hybris Commerce.
For example, if the license is based on certain assumed metrics (e.g. core-based) then need
to be aware in case these change during the project, e.g. architecture, sizing, etc.
Or maybe the customer has licensed only specific Hybris Commerce modules, so other
modules cannot be used without additional cost. So it’s important to understand these as
soon as possible.
Also, understand the licensing model and whether there are any key milestones that the
project team needs to plan around.
It’s essential to qualify potential projects/customers as early as possible to ensure there is a fit
on all sides. As a project proceeds through the phases, greater investments are made with
each phase, both regarding time and resources, and therefore also greater costs. It’s
therefore very important to establish as early as possible whether the project is viable, and
that the relevant parties can work together for the mutual benefit of succeeding in meeting the
project goals.
Often qualification occurs during the software license sales process, for example, during the
customer's vendor selection process. Sometimes it's afterward, for example, the customer
has already selected Hybris Commerce as the software platform, and now they need to
decide how to implement it. Here we are assuming this is a new customer and with their first
implementation project, although many of these topics will be applicable in other cases.
It is important that whoever is responsible for the project delivery is involved in this
qualification, working directly with sales or other involved teams. Often there is a history of
important topics from the early sales process, so it's also essential that sales are involved at
every step, at least until the first Engineering Phase kicks off, that is when the customer has
committed to the project.
Naturally, the sales team tend to be more optimistic regarding complexity and delivery,
whereas the project team tends to be more conservative. That's a key reason why the project
team needs to be directly involved in qualification, working closely with the sales team who
may already have set expectations with the customer regarding implementation dates, effort,
duration, and costs. If the project team gets involved too late in the process, it will be much
more challenging to reset any expectations. It's best to be realistic from the start.
The duration of this phase is variable from weeks to months since there is a limited level of
commitment from both parties as a contract has not yet been signed yet and there are many
internal and external factors and dependencies that can impact the process.
Qualification Activities
Often the sales team are the first contact point if it’s a new customer, or maybe someone else
from an account or customer management team if an existing customer.
They will have background information and very high-level information such as timescales,
business goals, rough project size/budget, challenges, etc.
These internal discussions allow very quick assessment whether it’s viable to engage or
whether an alternative option is more suitable.
Customer Alignment
After internal alignment, an initial high-level meeting should be arranged to allow the customer
and the project team to discuss and explore the why/what/how/when of the project.
This allows a quick assessment on both sides whether it’s viable to continue. It also gives the
project team an opportunity to provide feedback to the customer on areas they might need to
think more about before continuing with next steps.
Ballpark Estimate
The customer might want a clearer idea of how much the project will cost as part of the
qualification process and before proceeding further with the Initiation Phase.
This will be a very high-level estimate and is usually based on a requirements spreadsheet
provided by the customer, with some quick question-and-answer sessions to clarify
requirements with the customer.
This won’t be exact, but a ‘ball-park’ estimate expressed as a range using low/medium/high
estimates. Assumptions should also be documented together with the estimates.
This step is optional, as it’s challenging to reliably and accurately estimate a project in this
manner due to lack of information, and the range can be very wide, especially with all the
assumptions. It’s usually much more efficient and valuable to use these requirements as the
base for the following Initiation Phase workshop after qualification so that the customer can
explain each requirement in more depth and the project team can suggest alternative options
that the customer might not have considered. This usually produces a much more valuable
and accurate estimate.
Qualification Topics
Project Goals
Iterative Methodology
Determine which is the best methodology to meet the needs of the customer (Agile or
Iterative)
Determine how the customer’s internal decision making works. Are they top-down or do they
empower people? Are they a collaborative and dynamic organization or do all decisions need
to be approved at C-level?
If the customer is traditionally a Waterfall organization, it might be inadvisable to get them to
work in any other methodology. Even if they are initially willing, they may not be able to adapt
to anything else, and this may put the project at risk.
The amount of time expected from empowered customer representatives is significant. Will
the customer be able to provide single individuals responsibility for the business, technical or
project management decisions? Can they do this in addition to their "regular" job or can they
provide people full-time on the project?
B2B/B2C/PCM
Understand the type of project and type of customer, e.g. business-to-business (B2B),
business-to-customer (B2C), product content management (PCM), etc.
If it's a B2B business, they will be less demanding regarding fancy features, but will perhaps
need more hand-holding regarding eCommerce best practice, so might need more
consulting/coaching. These customers often have less demanding non-functional
requirements as they tend to have fewer users, but greater order sizes.
If it's a B2C business they will probably be more demanding regarding features, but maybe
too demanding and want to push the boundaries of the Hybris Commerce platform,
sometimes beyond its capabilities. They might also have more demanding non-functional
requirements.
If it's a pure PCM project, then there's unlikely to be much front-end work, and more
system/data integration. PCM projects can also be much more Cockpit-focused (Cockpits are
the Hybris Commerce business user applications), so it's good to know how much
customization is likely in this area as it could become complex if non-standard. There will also
likely be an existing eCommerce solution that could be a competitor to Hybris Commerce. If
so, this could create some concerns in the existing eCommerce team that need to be
managed.
Accelerator
Understand if expectations around ‘Accelerator’ have already been set with the customer. If
it's been described as “an Accelerator project,” this sometimes means the customer expects a
lot of their requirements are already met out-of-the-box with just some minor
development/configuration effort before any proper analysis has been completed.
Check if the customer has any other major projects running concurrently.
If there are two major dependent systems being developed in parallel, this can create a lot of
challenges, both from project management and technical perspectives.
From a project management perspective, it will be very important to manage the program
dependencies and risks. E.g. if there's a delay to one project it can have a major impact on
the second.
From a technical perspective, the system interfaces can become a moving target and cause a
significant amount of rework. E.g. if Hybris Commerce is taking a product feed from another
system and the other system is regularly changing the product attributes or structure, this can
have a big impact, not only for the interfaces but also the data model, service layer, and
everything else that sits on top of the data model in Hybris Commerce.
Timescales
Understand when the customer wants to start the project and when they need it to go live,
and what they mean by ‘start’ and ‘live.' Is 'start' the Foundation or Engineering Phase start
date? Is 'live' the hard or soft launch date (e.g. full production or limited friends and family)?
Or maybe there's a global rollout and associated live dates?
Understand what can potentially impact those dates, and whether they are fixed or likely to
move.
Check if the customer has any other timescales constraints that might impact the project, e.g.
strict production deployment windows. This can have a major impact on project planning.
Timescales are critical when managing capacity; there is no point engaging with a customer if
they need to start before the project team can engage.
Similarly, if the start date is long into the future and the project team is ready now, then the
risk of having a team on the bench needs to be managed.
Also, need to assess whether the dates are realistic.
Project Size/Complexity
Understand who will be responsible for the long-term development, support and operations
after the initial implementation project. This can have a major influence on the project
planning, dependencies, and risks.
If the customer takes long-term responsibility in-house, understand how this might impact the
team structure as these resources will need to be part of the project team. Also, need to
assess whether it's realistic for the customer to take it in-house. E.g. whether they are set-up
organizationally, have the right skills and experience, etc.
If responsibility is external, need to find out who will be providing these services and exactly
what services have been agreed. If a partner is involved, then need to understand how this
will work, who has accountability, how this works contractually, etc.
If part of the project team’s organization, need to identify other teams involved and ensure
they are involved in the initial planning as the customer will expect a ‘single face’ and may
expect the collaboration to be factored in automatically.
Partners
Understand the customer’s partner situation. If partners have previously been involved but not
anymore, understand their role and why are they not involved now. Or maybe a partner (or
several) are currently involved in which case need to understand their roles, how they work
together and their goals.
If partners have already been involved but not anymore, find out what they've already
delivered. Sometimes this can be leveraged; sometimes it can create additional challenges.
E.g. if they've already completed some development and charged the customer, the customer
may expect this to be reused regardless of quality.
Sometimes the customer has an incumbent partner in other parts of their business; maybe
this partner wants to get involved.
It's critical to understand the dynamics where there are multiple partners involved. The more
partners involved, the more complex the project can become. It’s very important the customer
and partners establish ways of working with aligned goals.
Hosting/Managed Services
Understand who will be providing hosting or managed services, i.e. who is responsible for the
production and other environments. Is this the customer? An external hosting company?
Don't underestimate the potential impact a poorly managed hosting set-up can have on a
project.
If provided by the customer, this can potentially become expensive for them, have long lead
times and questionable competence of their team and availability.
If provided by an external hosting company, has the customer already selected and
contracted the provider? If not, then this can impact environment preparation lead times and
potentially delay Engineering start dates. If they have, then the environments might already
be scoped and cost, in which case need to check they are correct otherwise it can have a
significant and unexpected impact on costs and lead times.
Regardless of who is providing the hosting/managed services, it's very important to
understand the services included. E.g. does it include deployments? How much access to the
environments will the project team have? These can have a significant impact on productivity
and the services required from the project team and therefore to include in the effort/costs
estimates.
Contracts
It's very important to understand the required contractual base for the project, e.g. fixed price
vs. T&M, and any other previously agreed on terms and conditions.
With the Iterative PDF either fixed price or T&M can be used. However, with fixed-price, a
robust Change Control system which includes time/cost calculations must be in place. It also
necessitates greater up-front requirements/design as the project team tries to understand all
risks and requirements before committing.
Location
Understand where the customer is located and where the project team will be located.
If the customer is distributed, then understand where their project teams are located and how
workable this is. If the project team is working closely with the customer IT team, but the
customer IT team is on the other side of the world and their business team in a completely
different location, this could become challenging for a highly collaborative project. It is less of
a challenge using an Iterative approach during the Engineering Phase as there is lesser
contact with the customer.
Check to see if there are any time zone or other location challenges, e.g. perhaps it's very
difficult to travel to the customer or there are travel restrictions for key people in the project
team.
It is important to know where customer or partner resources which are part of the project are
located. E.g. if there are offshore development resources, this needs to be carefully factored
into the planning as it may have an impact on delivery times.
Language
Understand the preferred language of everyone working on the project, and whether there is
a common language that everyone can speak well.
Also, understand if the documentation is written in the same or different language.
This can have a major impact if people cannot easily communicate both verbally or through
writing.
Culture
Consider the cultures of the people involved in the project and how this might impact the
project methodology used.
For example, in some cultures, it's rude to disagree with someone publicly, so workshops
need to be managed very carefully to ensure people can get their views across.
Remote delivery
Understand if the customer expects or needs an onsite presence or whether they are happy
to work with a remote delivery team.
If the customer needs a lot of onsite support, then need to assess how this will work from
travel perspective based on their location.
If the customer is happy to work with a remote delivery team, then need to assess how well
they can work in this style and whether it's a style they are experienced with. E.g. if customers
are not able to work efficiently and collaboratively with electronic communication tools, this
will quickly become a problem for a project team that's dependent on this form of
communication.
Regulatory Constraints
Check to see if the customer is subject to any regulatory constraints as this can have a
significant impact on a project.
For example, if the customer requires SOX compliance, then they will have much more rigid
documentation requirements and auditing processes that can significantly increase effort and
reduce velocity.
If they operate in an industry that requires signed-off functional requirements and design
specifications, such as the pharmaceutical industry, then the Iterative approach – which
mandates sign off before commencement of Engineering - may be the only option
Licensing
It’s important to understand what the customer has licensed with regards Hybris Commerce.
For example, if the license is based on certain assumed metrics (e.g. core-based) then need
to be aware in case these change during the project, e.g. architecture, sizing, etc.
Or maybe the customer has licensed only specific Hybris Commerce modules, so other
modules cannot be used without additional cost. So it’s important to understand these as
soon as possible.
Also, understand the licensing model and whether there are any key milestones that the
project team needs to plan around.
Ideally, it’s best to discuss and explore the why/what/how/when/cost/risks of the project face-
to-face with the customer on their premises. This allows:
Typically this workshop will be around 1-2 days. However, it can be slightly longer/shorter
depending on project size/complexity and the number of people involved. The key is that the
project team receives enough information to estimate high-level effort and create a high-level
project and cost plan.
Prepare Workshop
Preparation is key for the workshop. With only 1-2 days of workshop discussions, it's
important to have an agenda (a list of topics/features to be discussed) and to time-box, the
agenda to ensure all topics are covered at an appropriate depth. From a functional
perspective, the objective is not to get detailed requirements, but a high-level understanding
of complexity and prioritization for each feature to enable high-level estimation.
Project, functional, and technical expertise is needed from the project team representatives
for the workshop, so attendees need to be planned appropriately. Similarly, technical and
business experts from the customer side are also required. Also, any important dependent
third parties should be represented.
If a pre-sales team has previously been involved with the customer, it is helpful to see the
same demos that they gave to the customer beforehand, to understand the customer’s
expectations going into the workshop. Depending on the situation it might also be useful to
have the pre-sales person attend the workshop.
The workshop agenda should be agreed and finalized with the customer beforehand. Topics
should be time-boxed into 1-2 hour slots so that all the material can be covered.
For the functional topics, typically the customer provides a spreadsheet or other document
with their requirements wish list. This can be categorized and used as the functional agenda
structure. If not then a standard list of functional topics can be used.
Run Workshop
Tightly moderate time to ensure all topics are clarified only to a level that enables high-level
understanding and estimating. Sometimes customers focus on certain topics, especially
where there has been a lot of internal debate. It’s recommended the customer continues
these discussions internally after the workshop in preparation for the subsequent Foundation
Phase.
Discuss customer expectations on timelines, go-live dates, and scope while avoiding setting
expectations on being able to meet those before proper analysis and planning.
If discussion of a feature starts getting into lengthy discussions and too detailed, it is sufficient
to note it as an area that needs further elaboration which will result in an increased number of
person-days or Story Points to account for the uncertainty. Plus this also helps identify topics
that might need more time when planning subsequent Foundation Phase workshops.
Demos are only needed where they add value and facilitate the objectives of the workshop,
so don’t spend lots of time educating the customer on out-of-the-box functionality as this isn’t
the objective, and time will be taken from more important topics.
Document as much information as possible, this will be needed for later estimations. Most
important are the features to put in the Iterative PDF - Initiation Estimation Sheet, but
information related to technical, quality and project considerations should also be captured.
It is helpful to understand budget expectations but be aware that the customer may not want
to provide it and would prefer to receive a cost estimate based on their requested scope not
for the perceived budget.
Dates for customer to provide further input (e.g. diagrams, layouts, click dummies, etc.)
Dates for the project team to provide estimates and high-level project plans. Set expectations
that these will be high-level estimates subject to further exploration during Foundation Phase
workshops.
Agree on potential start dates for the Foundation Phase. This is required for high-level project
planning.
During this activity, the project team takes the information gathered during the qualification
and workshop activities, and all other provided information, and presents the customer with
proposed project plans and costs.
1. Estimation
2. Sizing
3. Planning
4. Presentation
Estimation
It’s important the appropriate people from the project team are involved in providing estimates
for the feature requirements identified during the workshops. This should involved people with
architectural, development and testing responsibilities.
Follow-up question-and-answer sessions should be arranged with the customer to clarify
outstanding uncertainties.
Assumptions should be clearly documented.
Normally person-days are used in the Iterative Framework, but if Story Points are being used
to estimate effort during the project, it is recommended these are used for these Initiation
Phase estimations. It’s important to start using these as early as possible, to educate the
customer and get them used to SP. Ultimately SP will be converted to person-days in the cost
planning.
Each feature should be estimated using low/medium/high effort so that each feature is given
three estimates to enable estimates and costs to be provided as a range. Note that this is at a
feature level and not at a granular user story level.
Sizing
Planning
During the workshops, the features will be organized into a logical flow for the build, and with
the small/medium/large person-day estimates for each feature can be loosely scheduled into
the relevant Sprint.
During the workshops, team structures and resourcing availability would have been
discussed. This allows an estimated development capacity to be created for each sprint and
therefore each release can be sized to accommodate the required scope by using the
estimated or historical velocity for the project team.
Together with the capacity planning, a project plan can now be created showing start/end
dates for dependent milestones.
Total costs can now be calculated based on resource and project plans. If using Story Points,
person-days can be calculated by calculating the number of person-days for each sprint.
Presentation
Now that estimates, sizing, and plans are created, they can be presented to the customer,
potentially with different options.
This will likely involve several more discussions and possible revisions to the plans as the
feature scope/timescales are adjusted to fit the customer's needs.
Hopefully, the customer will then decide the project is viable and wants to continue with the
subsequent Foundation Phase.
The following list of activities should be covered during the Foundation Phase:
The duration of the Foundation Phase (from start of workshops until deliverables are provided
to the customer) depends on several factors including:
As a guide the following scale can be used to estimate the duration of the Foundation Phase,
based on the total number of person-days (PD) estimated for the project as a whole during
the preceding Initiation Phase (including project management, architecture, business
analysis, development, and testing):
1000 PD = 16-week project. Two weeks onsite, one week offsite to create documentation
2000 PD = 32-week project. Four weeks onsite, two weeks offsite to create documentation
3000 PD = 50-week project. 6-7 weeks onsite, 2-3 week offsite to create documentation
This scale should be adapted to account for the other factors, and it’s usually better to plan
more days rather than less for the Foundation Phase as not enough planning can introduce
greater risk later.
Internal Kickoff
The project team should meet to establish ways of working and roles and responsibilities as
they prepare for the upcoming Foundation Phase workshops and project. At this time, the
team should also decide on a Definition of Done (DoD) and Iterative PDF - Definition of
Ready (DoR).
Prepare Workshop Agenda
Once the duration is known and the onsite/offsite days are planned, the agenda can be
defined and agreed with all relevant parties. As a guide, this should be based on the topics
discovered in Iterative PDF - Initiation Workshop, plus any other topics specific to the project.
Buffer workshops should also be planned to address new requirements that are identified
during the workshops and any overruns.
The offsite days can be organized as appropriate, either together at the end of the phase or
mixed with the onsite days. It is highly recommended to have some documentation effort
during or after the workshop days (e.g. at the end of each week) as documentation is a key
part of this phase. All documentation is then consolidated offsite during the final weeks of the
Foundation Phase.
It’s critical both the customer and the project team work together on this agenda, as often
there are resource dependencies or maybe a logical flow that will maximize workshop
efficiency.
These planning activities should be the responsibility of both the customer and project team’s
Project Managers.
Plan Workshop Attendees
When planning workshop attendees, it’s important to manage the appropriate level of
attendance, ensure the relevant people are invited, and their attendance is confirmed. Too
many individuals and discussions can become lengthy and inefficient; too few individuals and
topics might not be discussed in enough depth. Additionally, with too many people, the
physical workshop location can get difficult to manage comfortably, so this also needs to be
planned with the appropriate number of people in mind.
As well as ensuring the appropriate balance of numbers, it is also vital to ensure the right
balance of decision-making and knowledge, on both the customer side and the project team
side.
Typically it’s a good idea for the workshops to be held on the customer’s premises to ensure
availability of the required people from their side. Additionally seeing how the customer works
day-to-day and their working environment also helps the project team to understand the
customer better.
From the project team side, it’s, generally, not possible or even desirable for the whole team
to attend the workshops, so it is important to ensure attendance of key and trusted team
members that can represent the entire team in each area.
As a guide the following roles should be considered during the workshops (note that a single
person can perform multiple roles):
Project team:
Customer:
Creative design agency representative (if external party is responsible for creative designs)
Infrastructure representative (if customer Architect cannot cover)
Security team representative (if customer Architect cannot cover)
The project team’s capacity for the project should be calculated during the Initiation Phase
and reviewed early in the Foundation Phase to account for new information and factors. A
relatively accurate estimate of each functional area is required to provide an initial plan that
can be discussed with the client. This can be based on previous development times on other
similar completed project (e.g. PDP took 50 person-days, checkout took 70 person-days).
Set-up Sprint (also known as sprint zero) at the start of the Engineering Phase or towards the
back-end of the Foundation Phase
Implementation Sprints – the solution is only developed during these sprints, so this is where
the capacity needs to be calculated
Hardening Sprint (optional) – this tends to be a shorter sprint designed specifically for defect
fixing and will be the final sprint of the Engineering Phase
The number of sprints within an Engineering Phase is dictated by the customer’s scope, and
go-live date expectations and the duration for these sprints is agreed during the Initiation
Phase (e.g. typically either 2 or 3 weeks). Therefore only a fixed number of implementation
sprints can be planned within these known timescales.
a) Estimate the productivity of one fully experienced developer assuming 100% availability
and that they are dedicated 100% to development activities. This is the benchmark developer
and is the maximum person-days produced by any one person. Now factor in how much
ACTUAL time they have (considering holidays, sickness, meetings, training, etc.). This may
reduce it down to around 80% productive development time.
b) Now the velocity can be estimated for all other developers in relation to this benchmark
developer. For each developer resources estimate their % time allocated to development
activities and their % productivity compared with the benchmark developer. The productivity is
typically based on their experience level in relation to the benchmark developer so that if they
are relatively inexperienced, they might only be 50% productive compared with 100%
productive benchmark developer.
c) Now the potential total person-days are estimated per sprint, factor in specific holidays or
other known factors that will detract from productive time.
3. Total capacity calculation
When looking at all sprints within the Engineering Phase, it is worth considering that
productivity (therefore velocity) is likely to increase as the project goes on. So it is a good idea
to apply a productivity % against each sprint. So, for example, five developers at 80%
productivity during a 10-day sprint would give an average velocity of 40 person-day
development capability per sprint. Applying the ‘ramp-up’ factor, the Engineering Phase might
look like this:
Total PD 0 30 34 40 40 40 40 42 44 0 295
Now the estimated PD capacity is known for each implementation sprint, add up the totals in
each implementation sprints to give the total estimated Engineering PD capacity.
Research Topics
As the agenda is being prepared, there may be some topics the project team is unfamiliar
with, e.g. if the customer requires a new Hybris Commerce module that has only recently
been released.
These topics should be identified as early as possible, and appropriate time allocated to allow
the project team workshop attendees to research and learn about these topics in preparation
for the workshops.
Prepare Functional Requirements
The customer should prepare a business overview for each of the features to be discussed
during the Foundation Phase workshops.
The presenter should be a customer representative who is ultimately responsible for the
feature or able to understand/communicate the expected value to be obtained from it, so they
can fully explain the requirements, answer questions promptly, and make any appropriate
decisions related to the feature. In case immediate decisions cannot be made, the customer
representative should own the action to ensure a decision is made and communicated to the
project team as soon as possible.
If there are important technical aspects that need to be presented by someone else, then the
customer representative should be supported by the appropriate person that can fully explain
them, so that they are discussed together with the business requirements.
The customer should prepare a technical overview of any specific technical requirements, e.g.
integrations to external systems, and non-functional requirements related to the solution, e.g.
performance requirements.
The presenter should be a customer technical resource that can present the specific
technical/non-functional requirements or limitations as well as the impact the requirement will
have on other systems.
Prepare Demos
In addition to the customer presenting their requirements, the project team should also be
prepared to present the out-of-the-box Hybris Commerce options, standard business user
tools, examples of best practice, and any other relevant material.
Therefore it’s important these are prepared beforehand to provide a smooth and seamless
demo. This might involve setting up local environments on attendee laptops, setting up data,
or whatever is required to independently provide the demo (i.e. in case there is no Internet
access). It’s always a good idea to for two people to have these configured, just in case one
person’s environment isn’t working at the needed time.
Prepare Paper Cards (optional)
Although not always common during the Foundation Phase of an Iterative project, one
method of capturing requirements during the workshops can be using paper cards. The
project team’s Business Analyst will document requirements on paper cards with each card
representing a feature title, sub-feature title (if pre-defined) and requirements tracking tool ID
(if assigned). Paper cards representing features may be pre-populated in advance.
Prepare Workshop Room
It’s also crucial to prepare the workshop room itself to maximize efficiency and productivity.
Physical Facility
The physical room itself should be planned and prepared appropriately for the workshops to
ensure people are comfortable. Workshops can easily get tiring after many hours/days, so it’s
important to keep people as fresh and alert as possible. Cramped, hot and stuffy rooms with
no windows or ventilation can kill energy levels, leaving questions unasked and people just
wanting to leave as soon as possible. So ensure workshop rooms have good ventilation, are
appropriately sized for the planned attendees (and others who may decide to join), and
there’s plenty of water, tea, and coffee available!
Recording Equipment
If appropriate and permitted, it may be useful to record the workshop as this allows for project
stakeholders who are unable to attend the Foundation workshops to view the material
presented and for this material to be referenced at a later date if required. If so, it is important
to confirm the participant’s permission in advance and whether any special precautions must
be taken with the resulting material.
Presentation Materials
Workshops should be dynamic with people interacting and collaborating. As such it’s
important, there are enough whiteboards and flip charts to allow people to present designs
and ideas as needed. These should also be captured either using cameras or other methods.
Of course, there should also be a working, high-quality projector that can be clearly seen by
all attendees. There is nothing more frustrating than people spending lots of time trying to get
a projector working with their laptop; the resolution is poor, color is missing or other problems
that could have been avoided by prior testing of the equipment.
Internet Access
It’s important to ensure attendees have good quality Internet access both for presentations
(e.g. showing competitor solutions) and attendees (e.g. so they can contact non-attendees for
information without leaving the workshop).
1. Project kick-off
2. Define project governance, organization & structure
3. Define solution goals
4. Define functional requirements
5. Define non-functional requirements
6. Design architecture & system integrations
7. Define environments & tooling
8. Define quality management & testing strategy
9. Planning & prioritization
Documentation is another important activity that must be done in parallel to the above
activities, ideally either as a dedicated time at the end of each workshop or at the end of each
day or week. This will be dependent on the workshop agenda, how the project team prefers to
work and what fits best for the customer.
These activities do not need to be completed in the above sequence or separately, it’s often
more efficient to combine them where appropriate. The most important factor is they are all
completed properly so that high quality and accurate deliverables are provided at the end of
the Foundation Phase.
Project Kick-Off
The project vision should be presented by the customer (ideally the Project Sponsor) at the
beginning of the Foundation workshops and include the history, goals and expected business
value to be obtained from the project. To effectively kick-off a project it is important to ensure
that all parties and stakeholders understand the shared objectives.
During this workshop, the high-level project plan defined during the preceding Initiation Phase
will be presented to the team, as well as the specific goals for the current upcoming release.
This sets the context for the subsequent workshops.
Define Project Governance, Organization & Structure
The project governance, structure, and organization should be defined during the Foundation
workshops incorporating all project stakeholders. Roles and responsibilities should be
documented and clearly communicated, for example, responsibility for frontend code, cross-
browser compatibility testing, performance testing, the definition of acceptance criteria, and
infrastructure. This is documented as a RACI matrix in the Project Management
Definition deliverable.
Regular project meetings and communication channels should be defined and agreed. For
example:
Understanding the goals of the new solution is critical as these should be used as a reference
point for decision-making, e.g. during requirements prioritization. Therefore it is important
these are understood upfront during the Foundation Phase workshops, so everyone is
aligned. It's equally important to identify if goals are unrealistic and mitigate these
expectations as early as possible, resetting goals appropriately.
Pain points
Revenue / key performance indicators (KPIs)
Competitive advantage
Additionally, it's equally important to understand the consequences of NOT doing the project
and building the new solution. Often these are very powerful drivers in themselves, and it's
important to understand these, so it's recommended these are also explored during this
workshop.
Pain Points
Even if there's no existing solution there will likely be pain points in the customer's business
that the new solution may be able to resolve, perhaps that the customer hasn't considered
and may be identified as they explore the new solution in more depth.
Revenue / KPIs
Revenue targets and KPIs typically go hand in hand with goals and objectives, and may even
be outlined as part of the success criteria. These metrics can also be helpful to determine the
size and scale of the solution, along with projected growth. Typically these are marketing,
sales, or traffic related.
Competitive Advantage
Understanding the customer's competitors and their strategy to compete against them is very
useful. This can be done by:
1. Outlining all known and up-and-coming competitors and ranking them appropriately, e.g. in
terms of their eCommerce strengths/weaknesses.
2. Explore how they compete with each competitor, and whether there are areas they are trying
to catch them in, as well if there are areas they seek to be an innovator or gain a competitive
advantage.
3. Ask the simple question: what is the best thing the customer's biggest competitor is doing that
they aren't?
A thorough understanding of the customer's competitive situation can really help the project
team guide the new solution to maximum advantage, e.g. if a competitor is particularly strong
or weak in an aspect of their eCommerce offering, these can be used as reference points
during subsequent requirements analysis workshops.
Define Functional Requirements
During the Foundation workshops, the customer’s business and technical representatives
further elaborate upon the features for the current release as defined during the preceding
Initiation Phase. These sessions will be scheduled as defined by the workshop agenda that
was agreed before the workshops commence.
This guide will assume paper cards are being used to capture requirements during the
Foundation Phase, although other methods can also be used.
Feature Presentations
The following presentations are required in order to communicate the business and technical
requirements of a feature:
Business Presentation:
The customer representative responsible for the respective feature should communicate all
business requirements. Examples may include:
Feature overview
Expected business value
Mock-ups (screenshots) or layouts
Technical Presentation:
The customer representative and/or the supporting technical authority should communicate
any known technical considerations relating to the requested feature. Examples may include:
Rules/restrictions
Entity relationship diagrams
Data flow diagrams
System diagrams
Specific non-functional requirements
Analytics specification
Technical dependencies
Technical value to help subsequent prioritization
The business and technical presentations are often combined to make sessions more
efficient.
Q&A Session
Following each presentation a question-and-answer (Q&A) session allows the project team to
immediately clarify requirements and possibly suggest alternative options to ensure the
customer’s requirements are fully understood, and the best solution is decided. It’s important
to do this while the information is fresh in people’s minds and the relevant people are
available. This is also an excellent opportunity for the project team’s Business Analyst to
clarify the information captured on the paper cards during the presentations.
Playback Sessions
With an Iterative project, because the Foundation is longer Playback sessions can take place
throughout the on-site Foundation Phase, but will certainly also take place towards the end of
the on-site Foundation Phase where the information collected to date on each Functional area
is played back to the customer to ensure it has been captured accurately. Any
misunderstandings are corrected during these sessions and anything that needs further
clarification is discussed. If necessary further Playback sessions can be arranged.
Requirements Documentation
The aim is to define the requirements for the solution to a sufficient level of detail for:
Workshops
1-1 meetings with domain experts
Existing relevant customer documentation
Documentation from 3rd parties
Information is captured during the workshops by the Project Manager, Product Owner, and
Architect. This can be done in various forms (handwritten notes, a spreadsheet or word
document or an online Wiki page). Sessions can be recorded if agreed by the customer.
Capturing the information should not impact the flow of the workshops – it's a bad idea to
have the same person taking notes as is presenting. Time should be allowed each day during
the on-site phase for notes to be consolidated and validated whilst still fresh in the minds of
those running the workshops.
Once the workshops are complete, documentation will have to be written up in detail. This is
not usually done on the client site but once the Foundation workshops have finished.
Therefore it is important to let clients know that they will not start receiving documentation for
review and sign-off until perhaps a few weeks after the team leaves the client site.
Requirements documentation can be delivered and signed off in smaller chunks (formally by
functional area) or can be a single large document. Breaking it down can have distinct
advantages including:
However, some clients may require one large document for Functional requirements and
another for non-Functional requirements.
Feature Cards
It is often useful, but by no means mandatory, to produce Feature Cards of all the functionality
that is produced. Although this is very common in an Agile project, it is not such a high priority
during an Iterative project, and may not be achieve-able due to time constraints.This is
because, although the Foundation
INVEST
The acronym INVEST can be used as a checklist to assess the quality of a feature, sub-
feature or user story. This suggests a well-defined feature/subfeature/user story should be:
This should be used a guide, however, it’s not always possible to follow exactly, e.g.
sometimes sub-features are dependent on another sub-feature being implemented first.
Here is an example sub-feature card showing how paper cards can be used to document
requirements:
Front side:
Reverse-side:
The following example illustrates the relationship between a feature and a sub-feature in
paper card form:
Dependencies between sub-features can be visualized through the use of stickers on the
cards that display appropriate comments. It is important that dependencies are documented
to avoid features being dependent on other features being selected during release planning.
Estimation
During the Initiation Phase, high-level estimates would have been produced. One of the
purposes of the Foundation Phase is to be able to gather enough detail to refine all estimates
so that they are accurate enough to plan the Engineering and Deployment Phases in detail.
Once all information on a particular area has been gathered by the Business Analyst and
Architect (who will be present at all workshops), the tasks to build that functional area are
broken down into as much detail as possible, and (normally with the help of the Senior or
Lead Developer) detailed estimates given to each piece of work required to build the whole
solution.phases in detail. Once all information on a particular area has been gathered by the
Business Analyst and Architect (who will be present at all workshops), the tasks to build that
functional area are broken down into as much detail as possible, and (normally with the help
of the Senior or Lead Developer) detailed estimates given to each piece of work required to
build the whole solution.
Estimation Approaches
There are different approaches to estimation, and these can vary depending on the project
team’s preferences. Here we present a recommended approach that has been successfully
used in many projects (commonly referred to as ‘planning poker’):
1. With all people in view of the sub-features to be estimated, the Project Manager facilitates the
estimation activities.
2. The Business Analyst should provide an overview of the sub-feature.
3. The Project Manager decides whether the team is ready to estimate:
a. Ensures that all attendees are comfortable with providing estimates. If any participants are
uncomfortable with providing an estimate, more discussion should occur.
b. If further clarification or feedback is still required and the customer is unable to provide
enough information to enable the project team to estimate then the feature paper card (and
hence all subsequent related sub-feature cards), should be marked as blocked until further
information can be provided. Once sufficient information has been provided then the relevant
sub-feature/feature should be revisited either during a separate consolidation workshop or ad-
hoc as required.
4. During the estimation activity the project team focuses on a single sub-feature and estimates
using planning poker:
a. Provide a five-second countdown to select estimates
b. All people display their estimates at the end of the five-second countdown
c. Read each estimate aloud while assessing the range from the lowest to highest
d. Request feedback from those who have provided the lowest estimate
e. Request feedback from those who have provided the highest estimate
f. Refine estimates as a group and reach a consensus
g. Document the agreed final estimate on the associated paper card
Once the sub-features have been estimated, the paper cards should be placed on the release
wall within the ‘To be scheduled’ area underneath the associated feature title card.
Define Non-Functional Requirements
Non-functional requirements (NFRs) are equally important (if not more important) than
functional requirements. You can have the most perfect functional solution in the world, but if
it isn’t accessible because it can’t handle the number of users, not only does it not work, but it
can also have serious impacts on brand perception, lost customers and ultimately revenue.
Therefore the project team needs to ensure non-functional requirements are captured during
the technical presentations. Typically this is the role of the project team’s Architect to ensure
these are captured. Additionally, there should be dedicated workshop sessions specifically to
discuss the customer’s non-functional requirements for the solution generally. These usually
focus on what is commonly called the ‘ilities’, e.g. scalability, maintainability, operability,
upgradability and so on. It’s important these are covered separately as NFRs tend to overarch
all individual functional requirements.
NFRs are a vital input into the architecture and infrastructure workshops, and they can also
have a significant impact on planning and costs. Additionally, NFRs need to be known before
development can start (so before the Engineering Phase), as they have a significant influence
on architecture, technical design decisions, and testing effort. So it’s essential these are
thoroughly captured during the Foundation Phase and planned in from the start of the project.
The project team’s Business Analyst and Architect should document non-functional
requirements on paper cards in the same manner as sub-features so that they can be
prioritized and planned during the Foundation workshops. Non-functional requirements may
also be documented within acceptance criteria of a feature/subfeature to ensure that they are
met if essential for implementation. The information collected should form the basis of the
Non-Functional Requirements document deliverable to be provided by the project team’s
Architect.
Performance
Scalability
Capacity
Availability
Maintainability
Security
Regulatory
Rather than try to estimate each NFR individually which can be challenging, a better
approach is often to create a buffer to incorporate groups of NFRs together, e.g. a person-day
buffer. For example, a 100 person-day buffer for performance can be distributed evenly over
the entire Engineering Phase (i.e. if 10 Sprints, allocate 10 person-days per Sprint to
performance)
Design Architecture & System Integrations
High-level physical and logical architectures and integrations with third-party systems should
be investigated during the business and technical presentations. Early design activities such
as core data modeling activities can also be undertaken where it adds value to the
workshops, e.g. facilitates discussions or explains concepts. For example, this is commonly
done for catalogs, products, content, pricing, etc.
The project team should pay particular attention to any required system integrations and
ensure that the impact of any such integrations is sufficiently understood. If the project
involves integrating with a third-party system which is not managed by the customer or project
team, then representatives from the third-party should be in attendance during the relevant
feature business and technical presentations to provide additional feedback if required.
Define Environments & Tooling
Infrastructure environments and tooling are essential to the project. For example, if
infrastructure environments are not ready on time they will have a significant impact on overall
project timings, e.g. if there are no test environments to deploy to then no testing can occur,
and development is held up. There is always a lead-time to setting up these environments, so
they need to be specified as soon as possible, and timings built into the project plan.
It is recommended that the project team works closely with the customer to define required
infrastructure and environments (e.g. development, test, pre-production, production). The
requirements for these environments are likely to be dictated by the NFRs and prioritization of
features.
Tooling is also a vital topic that can easily cause delays and frustration if not properly
considered and planned up-front. For example, the project management tools (e.g. Jira), the
development tools (e.g. IDE, continuous integration, source code repository), testing tools
(e.g. performance testing), etc. There is always effort to set these up at the start of a project.
Changing them mid-way through a project is very time consuming and will likely cause
significant delays.
Define Quality Management & Testing Strategy
It’s imperative to define and agree how the solution will be tested throughout the project to
ensure the quality goals are met. Ultimately the customer needs to decide the quality goals as
it’s an investment that requires effort and therefore budget. However, it’s strongly
recommended this is properly considered and planned. Quality needs to be baked-in from day
one; it’s much more expensive to try and fix quality later.
Specific workshops should be allocated specifically to cover the different types of testing and
ensure responsibilities are agreed. A RACI matrix in the Quality Assurance Definition is a
good method to document who is responsible, who approves, who is consulted and who is
informed.
Feature tests
Integration tests
Acceptance tests
Deployment tests
Performance tests
Cross-browser compatibility tests
Post-sprint acceptance tests
System integration tests
Authorization tests
User acceptance tests
Security tests
Test data should also be discussed and planned during the workshops. Preparing test data
can take a significant amount of effort. The quality of the data is also very important, and data
cleansing can also be very time-consuming. This can be a major source of delays and quality
issues later if not planned properly.
Infrastructure environments are also a key input here. It’s essential that appropriate testing
environments are available when required. Tooling is also a key consideration and needs to
be discussed/agreed with the customer. The defect management process should also be
agreed with the customer.
This information forms the basis for the Quality Assurance Definition (QAD) deliverable, to be
published by the project team’s senior testing representative. The QAD template contains
additional information about these testing topics.
System integration testing and integration testing both test how the solution interacts with
other systems, but integration testing is performed by the project team and may use mocked
integration so that it is not impeded by external systems. Whereas system integration testing
is performed by the customer, and also includes testing of interactions in the external systems
that cannot be simulated through mocks.
Planning & Prioritization
The Iterative approach to planning differs quite considerably from the Agile methodology. With
Iterative, the customer is likely to have little or no involvement in the sequence in which
functionality is built. As the full build is generally done (during the Engineering Phase) prior to
anything being handed over to the customer, they have no real interest in the build sequence
and just need to concentrate on preparation for receiving the full build at the end of the
Engineering
Some planning activities will occur during the Foundation Phase, usually led by the project
team’s Project Manager in collaboration with the customer’s Project Manager. These will all
feed into the final planning activity. These activities are
1. Project planning
2. Engineering planning/build sequence
3. Cost planning
4. Risk analysis
Project Planning
Project planning refers to the planning activities required to complete the entire project. The
project plan will likely include activities and dates such as:
Additionally, the project plan will show the dependencies and associated activities and
milestones.
The Project Plan initially created during the Initiation Phase should be refined to now include
fixed phase timescales together with associated go-live dates. The plan may have been
adapted during the Foundation Phase workshops to account for agreed changes to capacity
and timescales, as the originals would have been based on some assumptions that might
have changed. In some cases, more than one plan may be presented to provide the customer
with some options.
The agreed Project Plan is then provided as a Foundation Phase deliverable and is agreed
with the customer.
Cost Planning
Cost planning activities must occur to provide the customer with a cost for the whole project.
The process for calculating costs will vary depending on various factors but is mainly
dependent on the level of effort and resource costs.
These costs are provided as a Foundation Phase deliverable called the Cost Plan.
Risk Analysis
Throughout the Foundation Phase workshops, the project team will identify risks from
different perspectives, e.g. technical, project management, quality. These need to be clearly
communicated and openly discussed with the customer and factored into any planning. The
project team’s Project Manager should capture all identified risks with probability, impact
and mitigation plans.
These risks are delivered as a Foundation Phase deliverable called the Risk Register.
Next Steps
The Foundation Phase should cover all topics in enough detail to identify/mitigate risks, and
give both the customer and the project team enough confidence and certainty to proceed with
the Engineering Phase.
This point will have completed any 'Proof of Concept' work to satisfy BOTH projects teams
that the proposed solution(s) will work to a satisfactory level.
Completion of the Foundation Phase is no guarantee that the remainder of the project will go
ahead. If the proposed solution has become too expensive, or cannot meet the required
timelines the customer may no longer wish to continue. Assuming the customer does wish to
continue, it is standard practice that a Statement of Work (SOW) is raised for all remaining
phases of the project.
Essentially, the Iterative Engineering Phase recommended here adopts some of the
techniques from Scrum, specifically ‘sprints’ and the activities that sit around them (Sprint
Planning, Retrospective etc.).
1. Set-up sprint (commonly called sprint zero) – preparation for the subsequent implementation
sprints, e.g. set-up tooling, environments, and test data.
2. Implementation sprints (multiple) – fixed duration software development iterations.
3. Hardening sprint – finalization of the software produced in the previous implementation sprints
in preparation for UAT.
There are also a number of parallel activities that can be planned as part of this phase,
although typically some of these are more likely to be included in the Deployment Phase. The
more of these that can be started during Engineering the better but using the Iterative
approach this can be more challenging as the code is often not handed over to the customer
until the end of the Engineering Phase.
The timings of any parallel testing activities (performance, security, integration) will vary from
project-to-project as they are all dependent on what has been developed, test data and
availability of test environments and resources. However, they are all very important and need
thorough up-front planning and continuous tracking and management. It is essential they all
start early enough to allow appropriate time for rectification in the implementation sprints.
The duration of the set-up sprint (often referred to as Sprint 0) will vary depending on the
project. However, it’s usually 2-3 weeks. It is important to ensure there is adequate
preparation time because otherwise the project team can be significantly blocked during the
first implementation sprint, which immediately puts the team under unnecessary pressure for
the rest of the project.
Usually, no functional development occurs during this sprint, however, sometimes this is
useful, for example, if a core feature is needed otherwise it blocks all other development.
The specific activities of the set-up sprint will vary depending on each project. However, it will
typically contain the following types of activities:
Infrastructure Set-Up
Development/test environments
Continuous integration environment
Source code repository
Code review tools and process
Software package delivery & deployment process
Development Set-Up
Sharing the knowledge gained during the Foundation Phase with the whole project team as
many people will not have attended the Foundation Phase workshops
New tools learning/training if the project team is unfamiliar with the selected tools
Tooling Set-Up
Complete the project task tracking tool set-up (if not already completed during the Foundation
Phase, e.g. Jira)
Project file sharing repository
Project knowledge sharing tools, e.g. wiki
Performance testing tools
Test automation tools
In the cases of very large projects (over a year in total), it is worth considering whether to split
the project into Releases. This is where the code will be released to the customer for testing
and possible deployment in phases. This must obviously be done with agreement from the
customer and planned very early (during the Foundation Phase). If taking the approach of
phased releases the following should be taken into consideration:
Too few sprints within a Release and the project team doesn’t get enough time create the
agreed solution, and to build the momentum and iron out the inevitable inefficiencies that exist
in any project team when they get started. The team also takes at least a couple of sprints to
get into a natural productive rhythm (also called cadence).
Too many sprints and inefficiencies start to creep back into the project team as the new
software being prepared for release becomes ever larger, e.g. increasing the amount of
testing effort, and the team naturally becomes less energized working in the same way for a
long period with the constant pressure of achieving sprint targets.
The recommended sprint duration is 2-3 weeks depending on the project context:
The shorter the duration, the greater the frequency and potential overhead of the start/end
sprint activities, which also prevents the team getting into a natural productive way of working
in each sprint, especially if it’s a distributed team.
The longer the duration, the greater chance for inefficiencies to creep into the project team as
sprint targets become too distant which risks creating a mentality of taking it easy at the start
of the sprint, then rushing at the end. It’s much better to have a sustainable pace from start-
to-finish that requires appropriately spaced sprint start/end points to check/reset goals.
Having a constant duration allows the team to optimize their ways of working to maximize
productivity and minimize inefficiencies. They know naturally what amount of work feels right,
how to time that work, and how to self-organize. This rhythm is very important; it becomes the
heartbeat of the team. Fixed sprint durations also makes reporting and tracking much simpler
and more transparent as velocity can be monitored more easily.
The sprint duration should never be changed mid-sprint, even if the target is not met or if user
stories or tasks are almost but not quite finished. These sprints are tightly time-boxed to
ensure the impact on overall project timelines is not changed.
The number and duration of sprints are also important because they drive the potential go-live
dates of the project. The more sprints, the more software that is produced, the longer the time
needed for the Deployment Phase. So these also need to be balanced with any external
dependencies and required customer go-live dates.
1. Sprint pre-planning
2. Sprint planning
3. Sprint execution
4. Sprint review/demo (optional)
5. Sprint retrospective
1. Sprint Pre-Planning
Sprint pre-planning needs to occur one sprint ahead and be completed before the start of
each implementation sprint. This is very important, otherwise, sprint productivity will be
significantly impacted. Instead of being done beforehand this preparation work will occur
during the sprint itself, which will inevitably create inefficiencies as people are blocked waiting
for information or as new dependencies are identified.
a) Review the sprint target capacity (Story Points or Person-Days) based on the project
team’s availability and historical or estimated velocity. This should account for the capacity
differences per sprint (e.g. due to holidays, training, resource allocation, previous velocity
etc.). This task is typically performed by the project team’s Project Manager, then presented
and explained to the project team during preparation and planning activities. It is very
important the team accept this sprint target capacity as they need to commit to achieving it,
and it may need to be adjusted after feedback from the team.
b) Check the sum of the Story Points or Person-Days delivered in previous sprints in the
release so far, plus the sum of the velocity targets for all remaining implementation sprints,
still equals the overall velocity target for the Engineering Phase that was calculated during
Foundation. If not then potentially the Engineering Phase target needs to be revised or
reviewed to ensure that all agreed software can be delivered. This is the responsibility of the
project team’s Project Manager.
c) Tasks/User stories will have already been earmarked for the upcoming Sprint. These
should be double-checked and assigned to a Developer.
d) Before a backlog item enters the subsequent sprint planning activity, it should meet the
project team’s Definition of Ready (DoR) to ensure it is ‘ready’ for the sprint. The DoR
ensures that all necessary pre-requisites have been met prior to a task being scheduled in a
sprint. If the DoR isn’t met, it shouldn’t enter the sprint. See the Definition of
Ready deliverable for more details
e) Prepare the sprint by selecting all user stories and other backlog items for the sprint.
This can also include some future task assignments as it can sometimes be valuable to do
some advanced planning to assist in the selection of tasks for the next sprint so that
specialized skills are leveraged. Tasks can be presented via a physical board (if the team are
in a single location), or, if the team are dispersed, via a project task-tracking tool and shared
with remote team members electronically.
Once sprint preparation is completed, the project team is ready for sprint planning. This is
officially the start of the sprint. Its purpose is to assess the pre-selected tasks and discuss the
requirements of each task as a group in order to check dependencies, assign individual
resources to tasks if not pre-assigned and ensure that each task is sufficiently understood
prior to commencing work. All members of the project team should attend sprint planning.
Typically sprint planning is performed as a single time-boxed meeting 1-2 hours in duration,
depending on team size and assuming appropriate sprint preparation beforehand. If this
meeting takes significantly longer, it is likely preparation wasn’t completed properly.
a) Overview of the sprint’s estimation target and assumed resource availability provided by
the project team’s Project Manager as prepared during sprint preparation. If necessary, the
project team members can provide feedback or raise concerns that can then be incorporated
into the plans as appropriate, however, this should be avoided with proper sprint preparation
as amending plans is inefficient, and wastes effort already spent during sprint preparation.
It is very important the team buys-into and commits to the target to ensure maximum
motivation to achieving the target. If teams do not believe the target is realistic it will likely
have a significant impact on motivation and therefore productivity. Pushing the team to
achieve unrealistic targets with significant overtime might work in the short-term, however is
well-proven to create much greater longer-term negative impacts, e.g. quality issues,
demotivation, tiredness, attrition, etc. Therefore it’s very important the target is realistic whilst
also being in line with the overall agreed release target.
b) Sprint features, user stories (where used) and tasks should be presented individually. This
may include layouts, mock-ups, click dummies, etc. This task is undertaken by the project
team’s Business Analyst with the Architect and Lead Developer providing technical input as
appropriate. The functionality is reviewed by the team and elaborated as required. The story
point estimate is reviewed so that team members are able to raise a flag if they think the
estimate is low based on what they have learned since the original estimates provided in the
Foundation Phase.
c) Technical planning for the sprint is undertaken by the project team’s Architect and
development team.
d) To motivate the team it is good idea to assign a reward for meeting the estimation target at
the end of the sprint e.g. a team lunch, dinner or other favoured activity.
3. Sprint Execution
Sprint execution is the majority of time spent during the implementation sprint and is focused
on the completion of the user stories and tasks selected during the sprint planning.
Completion means each task/user story passes the Definition of Done (DoD). The Sprint is
considered a success if all agreed tasks/user stories that were included in the Sprint at the
start are completed to the DoD.
Incomplete tasks need to be factored into the following sprint. There are no hard and fast
rules as to how this is done, but it is very important that leftover tasks are taken into
consideration during final Sprint planning. A 10 person-day task may be 90% complete at the
end of a sprint which means that a day is left to complete this task, and this will have to be
included in the next sprint. This can either be done by increasing the target by one day (e.g.
increasing it from 50 to 51) or by keeping the original target of 50 and using contingency that
was built into the Engineering Phase (perhaps in the hardening sprint). The task would, of
course, be completed in the next sprint and not wait until the hardening sprint.
During an implementation sprint execution there are various collaboration and meeting
events:
The daily stand-up should be held every working day ideally in the morning. For remote
teams, this can be done via screen sharing/phone. Co-located teams should have a proper
meeting room or can simply do it within their general working space if the entire team sits
together and does not disturb others. The duration depends on team size but should not
exceed 15 minutes.
The weekly working group meeting is to track the project status within each of the project’s
workstreams represented by key representatives – those who are closely involved in the
running and shaping of the project, i.e. the customer, project team and other 3 rd parties e.g.
hosting providers, design agencies, etc. Any concerns should be raised so that risks can be
highlighted and managed. This meeting should occur once a week and with duration of 0.5-
1.5h depending on team and project size. Both the customer and the project team’s Project
Manager should summarize all input from their respective workstream representatives (plus
appropriate 3rd parties), and document them in simple, shared reports before the meeting.
The meeting itself should be done via screen sharing/phone as participants will join from
various locations. The project team’s Project Manager should drive and moderate the
meeting. However, each workstream owner should present his status to the group and
answer questions that may come up. After all the streams have presented their status the
group should review the risk log and update status, track new risks, review existing actions
and document new actions, etc. Sometimes Retrospective actions relevant to the customer
can also be discussed at this meeting, and appropriate actions put into place if required.
Again the project team’s Project Manager should moderate this.
Instant communication channels are useful for all teams, but especially for distributed
teams (e.g. Skype, IM).
Other meetings can, of course, can be planned as needed, depending on the project context.
The key consideration is they must be efficient and provide value in line with the goals of the
project.
During sprint execution, progress is continuously monitored using physical task boards and/or
electronic project tracking tools (e.g. Jira). This helps the project team and to customer know
where the team is regarding delivered Story Points or Person-Days, the status of tasks/user
stories/sub-tasks and to identify bottlenecks.
At the end of the sprint, a Customer Report can be produced if required showing working
completed and any new risks that have arisen during the Sprint, but this may not be
necessary if the weekly working group meeting is being performed efficiently.
4. Sprint Review
The sprint review occurs at the end of the implementation sprint. This is an opportunity for
members of the project team to present completed user stories and tasks to the rest of the
team. Typically it is performed as a single time-boxed meeting 1-2 hours in duration.
Each developer should present what they implemented during the sprint. This must be
prepared in advance of the sprint review (e.g. test data, login credentials, the method to
receive email and whatever else may be required). Having developers present their work is a
good way to increase motivation and quality during the sprint as people naturally want to
show something significant to the rest of the team. It’s also a good exercise in improving their
communication and presentation skills, and means every member of the team should be
aware of other work being carried out within the team.
This meeting is usually internal. However, if the customer or other external developers are
members of the project team they should be included. The customer Project Manager and
Business Analyst may join, preferably in a listen-only mode.
5. Sprint Retrospective
After the sprint review meeting, the whole team gets together for a sprint retrospective
meeting. This is usually time-boxed for no more than 1 hour. It’s an opportunity to reflect on
the sprint to highlight achievements and discuss what went well and what can be improved in
the next sprint. This activity officially marks the end of the implementation sprint, after which
the team is ready for the sprint planning and start of the next sprint.
a) Reflect on what went well during the previous sprint and define whether any actions are
required to maintain the positive experiences.
b) Discuss areas that can be improved and what can be done to improve them. Actions
should be clearly defined with individual resources assigned to each.
c) Review the actions decided from the last sprint and whether they were achieved.
d) All feedback and agreed actions should be documented and be accessible to the project
team.
6. Customer Demo (optional)
The Customer Demonstrations can be done at any point during the Engineering Phase to
show what had been completed. However, this is NOT recommended best practice in the
Iterative methodology as it:
The focus on the non-functional requirement testing typically includes software security
scans, penetration testing, PCI compliance review and other regulatory tests that are
mandated by the project's industry.
The duration of the hardening sprint depends on the number and duration of previous
implementation sprints, and the amount of software developed, however, it would not
normally exceed the length of an implementation sprint (e.g. 3 weeks)
The example plan below shows the time where customer business users are testing the
solution highlighted in red: New document here
Integration Testing
Once the Engineering Phase is complete, all the elements of the custom code and 3 rd party
software have to be integrated and tested at a high level to ensure that they all work
consistently together. The code may integrate with any 3 rd party software either directly or
through a ‘middleware’ layer which will also need to be tested. Normally, this is a progressive
process during the build phase but is only fully completed at the end of Engineering or early in
the Deployment Phase. Therefore a certain amount of integration testing and regression
testing (to ensure previously working software is not broken by any new integrations) needs to
take place before User Acceptance Testing can start.
User acceptance testing (UAT) is the formal acceptance of the delivered solution, i.e. testing
of the deliverables of the Engineering Phase. It is a period of several weeks or even months
(depending on the project size) following the hardening sprint during which the customer
performs comprehensive end-to-end testing. Preferably this is done by the business users
who will use the solution after go-live, but often dedicated testing professionals are brought in
to assist with this task.
The duration of the UAT period is usually proportionate to the duration of the implementation
sprints, then adapted for complexity, testing efficiency, and other factors. During the
preceding hardening sprint, the project team has validated that all UAT pre-requisites are
complete and the UAT environments are ready.
The logistics of the UAT period are discussed during the Foundation Phase and documented
in the Quality Assurance Definition and Project Management Definition, and any contractual
specifics of the acceptance process will be defined in the contract between the customer and
the project team organization. It is valuable for the project team and customer to revisit the
planned logistics and discuss the schedule, meetings, tools and workflow during the
Engineering Phase.
During UAT, the customer is testing the solution and reporting issues; then the project team is
determining whether they are defects or scope items, and prioritizing and fixing defects.
The UAT period is not for the development of new features. Feature freeze occurs at the end
of the implementation sprints, and during this period is too late to create new features without
creating a significant risk to the quality of the solution.
UAT is formal because it results in the formal acceptance of the delivered solution. This
acceptance is explicit (e.g. a signed acceptance letter), followed by go-live.
However, unlike other activities, formal UAT cannot be time-boxed as it only ends when the
customer has accepted the deliverables. Acceptance cannot be forced if there are significant
non-conformance issues related to the Acceptance Criteria.
1. A software package is provided by the project team to the customer after the end of the
hardening sprint, together with documented functional/non-functional requirements and their
agreed acceptance criteria.
2. The customer has X days to report non-conformance against these acceptance criteria.
3. The project team has Y days to resolve issues and provide resolutions in another software
package.
4. The customer has Z days to re-test only those reported non-conformance issues and report
further non-conformance against them (this prevents the UAT period being extended
indefinitely).
Then back to step 3 until no further significant non-conformance issues are reported.
All code should be tested by a tester/QA independently of the developer that wrote the code.
Also, it is recommended that a Continuous Integration approach is taken where all developed
code is merged into a single ‘master branch.' This will expose any defects/bugs caused as a
result of the interaction or merging between separate pieces of code. It is also recommended
that regular ‘regression’ tests (ideally automated) are performed on the branch to ensure that
previously stable code is not now broken.
UAT
Ensure delivered tasks/user stories meet the acceptance criteria agreed during the
implementation sprints.
It is highly recommended to create automated acceptance tests against these acceptance
criteria during the implementation sprints, e.g. make this part of the Definition of Done. This
will greatly decrease the chances of issues being found during by the customer’s business
users during UAT.
Ensure interfaces to external systems work as expected and meet Acceptance Criteria
agreed during the Foundation Phase.
It’s highly recommended that internal integration testing starts this as soon as possible during
the implementation sprints. This requires interface related development to be prioritized
accordingly and systems to be connected in the respective test environments.
Effective testing is dependent on the readiness of appropriate test environments and
representative test data. This usually requires significant planning which should start as soon
as possible.
Performance Testing:
Security Testing:
Warranty
Although not discussed in depth here, it is important to consider the warranty. Once the
customer has accepted the solution conforms to the acceptance criteria (either explicitly or
implicitly), the solution will often be covered by a warranty period agreed between the
customer and the project team. The duration of this period will vary between projects and will
be defined in any contract between the
parties.
The project team should estimate the effort involved to support the warranty period and factor
this into their project planning from both a cost and resourcing perspective.
Deployment Activities
The specific activities of the Deployment Phase can vary depending on the project, but
with the Iterative methodology, software testing is done during this phase. The software
will have been developed and tested internally in the preceding Engineering Phase, but this is
likely the first chance the customer would have had to do (full end-to-end) testing. No new
functional development should be planned during the Deployment Phase. However, capacity
should be reserved for fixing defects that may be found during this time.
Often the customer will push for additional development during this phase to try and squeeze
in some extra features. This is very high risk and should be strongly resisted as it creates a
major distraction for the project team as they aren’t focusing on Deployment Phase activities,
and these new features are unlikely to be properly tested. Late changes will very likely create
quality issues, which will cause later problems and negatively impact the success of the go-
live. Any new features required should be put into a new, future release.
Typically the Deployment Phase can be split into two distinct activity groups (activities
may vary depending on the project):
Pre-go-live activities
Post-go-live activities
Resources should be dedicated and made available for ‘post-live support.' This is
supplementary to the customer’s standard 1st/2nd/3rd line support model that should also be in
place with their incident/problem management processes. Post-live support during the
Deployment Phase is provided by members of the project team who are dedicated and
assigned specifically to support the standard support team in a hyper-care model, i.e. to
provide deep expert knowledge and fast responses to incidents.
Having members of the project team dedicated to post-live support is an insurance policy for
the customer. They are there to ensure smooth running during this most critical time after go-
live. Standard support teams typically work to defined SLAs. However, the post-live support
team provided during the Deployment Phase are there to work as quickly and efficiently as
possible to resolve/workaround all issues without requiring the delay and overhead of
escalations via the 1st/2nd support lines.
Typical issues tackled during post-live support can be environmental, operational, data or
performance related. These can be complex issues that might take the standard support team
a lot longer to investigate/resolve. See Issue Reporting and Escalation Recommended
Practices - Recommended Practice.
Resources need to be planned ahead of time to be available as appropriate, e.g. 24/7 if
required. See After Hours Support Recommended Practices - Recommended Practices
Deliverables for the Deployment Phase would typically be a signed Acceptance Letter from
the customer and the deployed code itself. It could also include any supporting documentation
for the project/software that was agreed with the customer such as run-books and training
material. The phase finishes when the post-live support is ended. From this point, all support
issues are handled by the customer’s standard 1st/2nd/3rd line support model. A proper hand-
off between the project team and the support team will ensure a smooth transition of the on-
going operation. See Application Management Hand-off Checklist Recommended Practices
Cutover planning needs to start from the very beginning of the project during the project
Initiation Phase, so even before the initial Foundation Phase of the first release. The
preparation activities will vary from project to project depending on the context and will run in
parallel and often independently to the project phases. However, there will be dependencies
that need to be planned and managed between cutover preparation and the project phases,
e.g., if development work is required for cutover activities. The cutover go-live itself will be
managed during the Deployment Phase.
Essentially cutover planning, preparation, and execution run the entire duration of a release.
However, there are two distinct types of activities to plan:
1. Preparation activities – these need to be completed before a go-live decision can be made,
i.e., incomplete activities may prevent go-live.
2. Execution activities – these are completed around the go-live event itself once all
preparation is complete and the go-live decision has been confirmed.
Cutover preparation activities will vary depending on the specific context of a particular
project. However typical preparation activities include:
The cutover strategy must be agreed with all parties right from the start of the project during
the Initiation Phase, as it will have a direct impact on the release roadmap, timelines,
resources, prioritization, and many other important decisions.
Time constraints: e.g., any IT or business blackout period when no cutover activity should be
planned, e.g., during key sales periods.
Soft launch vs hard launch: Promote the idea of frequent releases. If a “big-bang” approach is
taken, the planning should consider the risks associated.
System dependencies: Call out any dependencies with other on-going & dependent
integration projects.
Legacy system: If the solution is to replace a legacy system, the cutover strategy needs to
include the migration or conversion steps from business, technical and data perspectives to
ensure minimal impact and risk.
Resources outside of the project team may be involved in go-live activities. The resource
requirements and availability need to be confirmed during the Engineering Phase. In some
cases, go-live execution activities will occur outside office hours which need to be factored in
the resource plan.
The deployment team organization needs to be planned and shared with contact information.
The decision maker and escalation path need to be in place in case an emergency or if an
unforeseen situation is encountered during go-live.
Business Preparation
Change management is an important part of cutover planning. The customer needs to define
a strategy that will enable acceptance and deliver the expected business value of the new
solution. The amount of change management required varies by organization. It can involve
tasks such as promoting new processes and functionalities, a communication strategy and
enabling end users via training.
End-user training is designed for business users and administrators to enable them to
perform their responsibilities based on the implemented solution and workflow processes.
This is different to standard Hybris Commerce product training that is training based on the
core underlying Hybris Commerce product, on top of which the customer’s solution has been
implemented. During the Foundation Phase, the end-user training needs are discussed so
that material preparation and training delivery are scheduled appropriately.
Typical end-users include:
Content managers for managing web content, page layouts, images, etc.
Product managers for managing products, catalogs, prices, product content, etc.
Customer service agents for assisting customers with orders, payments, site usage, etc.
Administrators for managing the solution itself, e.g., users, groups, passwords, structures, etc.
The project team typically provides end-user training as they have the best knowledge of the
implemented solution. This training can be provided as classroom or train-the-trainer sessions
depending on the needs of the customer. If train-the-trainer then one or more customer
trainers will be enabled by the project team so that these customer trainers can train the other
business end-users.
In either case, ideally, the training contains a large portion of practical exercises that need to
be prepared up front. Training sessions are highly dependent on an appropriate and stable
training environment and representative data. This needs careful upfront planning. Otherwise,
environment and data issues can cause significant disruption and frustration during the
training.
Technical Preparation
The go-live checklist covers all the technical steps that are required to take during
deployment. At a high level, the hosting infrastructure needs to be planned during the
Initiation Phase. The provisioning of the development and test environments is planned during
the Foundation Phase. Production hardening and readiness are planned during the
Engineering Phase.
Documentation
Documentation needs might include user manuals, help guides, administration guides,
deployment guides and training materials. These documentation requirements need to be
identified during Foundation Phase, then appropriate effort, preparation, and completion of
the documentation are planned accordingly during the Engineering Phase.
Transition Plan
Transition refers to the hand-over of the solution for long-term application management or
development after go-live. This long-term model should be agreed upfront during the Initiation
Phase so it can be incorporated into the project planning. Hand-over topics will typically
include:
During the Engineering Phase, the knowledge transfer activities can start on an on-going
basis (e.g., people shadowing/being part of day-to-day project work/learning by doing), or
during concentrated knowledge transfer sessions.
Backup / Restore Process
It is very costly to have any problem during deployment that causes interruptions in the
production site. It is, therefore, essential to have a backup and restore process in place to
recover from potentially failed deployments. These processes should be defined during the
Engineering Phase and tested as early as possible to allow enough time to correct any issues
and re-test.
Batch Process
Batch processing represents any set of automated tasks (jobs) that are executed without user
intervention. In the context of a Hybris Commerce system, batch processing includes
CronJobs, Impex Jobs and any integration process such as those which transmit data to or
from Hybris Commerce and ERP or other master data repositories, order processing, pricing,
inventory, and business intelligence or reporting. Batch processing can also include system
maintenance routines such as data backup and cleanup.
These processes should be defined as requirements during the Foundation Phase, then
designed/built/tested during the Engineering Phase.
Data Readiness
Even with the best designed, developed and tested solution, if the underlying data is poor
quality it can have a major impact on the solution functionality, performance, and general
behavior, potentially causing a significant amount of user frustration and issues.
The common examples of key data include customers, employees, orders/carts, promotion
and CMS content & media.
Data Migration – The data migration requirements should be defined during Foundation
Phase. This strategy covers how to migrate data from other systems into SAP Hybris
Commerce, perhaps from an existing solution being replaced. It also needs to consider
changes to the data model. Data migration often requires the development of ETL-type
processes during the Engineering Phase which needs up-front planning. It is also important to
consider data protection issues when working with real customer data. These are the
common scenarios of data migration:
Getting existing data from an existing system into a new SAP Hybris Commerce
implementation (see Data Migration)
Moving data from one database to another (see Data Migration)
Moving data between SAP Hybris environments (see Data Migration and Options for
Refreshing CMS Content Between Environments)
Data Creation – During the early implementation sprints, there is typically a lot of changes to
the data model requiring the Hybris Commerce system to be reinitialized with each sprint
deployment, which clears the database of all structures and data. At some point, the project
team needs to stop re-initializing the system with each sprint deployment so that data can be
loaded, enriched and persisted between deployments in preparation for testing and go-live
(e.g., product and content data). This needs to be planned ahead of time and often has data
and resource dependencies.
Data Cleansing - Imported data often comes from a variety of different sources, with
questionable data quality. For example, properly working facetted search and navigation is
100% dependent on high-quality data on which the search indexes are built. So if there’s a
color facet and there’s a ‘green’ and ‘greenn’ (misspelled) value, there will be two values
shown instead of one, or the ‘green’ value is used, and it misses the product with the
misspelled value. So the quality of source data needs to be assessed from the start of the
project during the Foundation Phase and appropriate time and resources planned to ensure
it’s corrected before being imported for go-live.
Go-live Checklist
A go-live checklist is essential to ensure that no steps are missed during deployment to the
live production environment. This checklist should contain task descriptions, dependencies,
owner, and status. The checklist is defined during the Engineering Phase and will be
reviewed with the team during the Deployment Phase.
Cutover execution activities are completed around the go-live event itself once all preparation
is complete and the go-live decision has been confirmed. These will generally consist of:
1. Preparation tasks leading up to go-live day, e.g., validating the go-live checklist, final testing
of system integration points, etc.
2. Preliminary tasks on go-live day, e.g., stopping transactions to the solution being replaced
3. Go-live activities, e.g., removing holding page
4. Immediate post-live activities, e.g., testing end-to-end transactions, monitoring system
resources, etc.
5. Activities following go-live day, e.g., continuous monitoring of transactions, system resources,
responding and resolving post-live issues as quickly as possible
Cross-Discipline Practices
Deployment Architecture
Software Architecture
Solution Architecture
Integration Architecture
Development
Performance Tuning
The OWASP Top Ten Recommended Protection Practices for Hybris
Business Requirements
Products
Pricing, Stock, and Promotions
Payments
Storefront Customer Journey
Order Management
Customer Services
Search Engine Optimization
B2B Features
Business and Administration Tools
Other Considerations
Non Functional Requirements
Data Migration Requirements
Quality Management
Project Management
A Hybris Commerce solution is managed in the same way, and consists of the same activities
and can be represented in the following lifecycle diagram:
1. Definition – what are the requirements of the solution, what needs to be delivered
2. Planning – how and when it will be delivered
3. Designing – what will it look like
4. Development – building the solution
5. Testing – ensuring the built solution works as expected and required
6. Deployment – delivering the solution to the live environment to be used by end users
7. Management – ensuring the solution runs efficiently
8. Then the cycle repeats with the next iteration as the solution evolves over time and new
requirements are defined feeding back into the planning step