Illustrates practices and techniques that compliment agile development methods such as Scrum

1. John Liebenau
Enterprise Architecture / Software Engineering © 2017 John Liebenau 1
Agile Development Method
Evolving Scrum to be more effective

2. John Liebenau
Enterprise Architecture / Software Engineering 2
Foundations
Unified Team
All members of a team must have the ability to work on any item in the team’s sprint backlog relative to their role. For example, all
developers in the team must be able to work on development tasks from any of the work items (i.e. stories) in the backlog.
Backlog Grooming
All items in the product backlog must be iteratively estimated and prioritized. This usually occurs in multiple iterations where the
initial iteration has a very rough estimate and priority which is then refined in successive iterations.
Velocity-based Work Capacity
A team may allocate story points for the next sprint that is less than or equal to the team’s current velocity (calculated as a
weighted average of past sprint velocities)—no exceptions!
Priority-based Work Allocation
Backlog items with the highest priorities are allocated—according to best fit—to the next sprint.
Priority-based Work Focus
Team members work on the highest priority tasks until they either 1) complete the task or 2) the task is blocked. In the case of 2,
the team member then begins working on the next highest priority task until the higher priority task become unblocked.

3. John Liebenau
Enterprise Architecture / Software Engineering 3
Iterative Development Method
Sprint Planning
1. Calculate the current planned velocity:
plannedVelocitycurrent = 0.3  actualVelocitycurrent-1 + 0.7  plannedVelocitycurrent-1
2. Perform object-oriented analysis on the highest priority work items in the backlog and refine their priorities and estimates if needed.
3. Break down work items into tasks.
4. Allocate as many of the highest priority work items to the current sprint where the sum of the work item points do not exceed the current expected
velocity.
5. Determine owners of the work items (ideally self-selecting)
6. Determine assignment of team members to tasks that minimizes blocking (ideally self-selecting)
Not Started
Completed
Blocked In Progress Paused
Task Selected
Task Completed
Task Blocked
Task Unblocked
Higher Priority
Task Unblocked
Higher Priority
Task Completed
Higher Priority
Task Blocked
Sprint Retrospective
1. Record actual velocity (sum of completed work item points)
2. Identify what worked, what did not work, and what can be improved
3. Define time-boxed action items for improvements and assign owners (ideally self-selecting)
Sprint Execution
1. Team members work on their highest priority task until they:
– complete the task or
– the task is blocked.
2. If a task is blocked, the team member begins working on
their next highest priority task until the higher priority task
become unblocked, at which point they go back to sprint
execution step 1.

4. John Liebenau
Enterprise Architecture / Software Engineering
Evolution (Not Revolution)
Evolving the method is fundamental to agile development
• Retrospectives enable method fine-tuning
• Periodic reassessments enable deeper reflection of ongoing challenges
• Adaptation is necessary to keep method effective
Balancing change and stability is necessary for sustainability
• Organized change is necessary to address persistent challenges
• But change introduces disruption and requires time to absorb
• Stability provides the opportunity to achieve mastery
• But too much stability leads to stagnation
• Goal is to establish a balance between change and stability that enables sustainable effectiveness
and long-term, incremental improvement
4

5. John Liebenau
Enterprise Architecture / Software Engineering
Primary Roles
5
Team
Tester
Architecture Owner
Analyst Developer
Product Owner
Team Member
Scrum Master
1
1..*
is-a
is-a is-a

6. John Liebenau
Enterprise Architecture / Software Engineering
Work Products
6
Use-Case Model
Analysis Model
Use-Case
Task List
Release Plan
Product Backlog
1 N
1
N
N
1
1
1
1
N
1
N
1 N 1 N
contains and prioritizes
contains
contains
maps stories to sprints
decomposed into tasks
made up of
realizes
generates
provides estimate for
Story
Business Requirement
N
N
describes behavioral requirements as interactions
Use-Case Realization

7. John Liebenau
Enterprise Architecture / Software Engineering
Use-Case States
7
Identified
 Use-Case and participating Actors have
been named
 Use-Case has been summarized
Described
 Use-Case flows have been described
 Constituent User-Stories have been
identified
Realized
 Analysis level class diagram has been
created to describe system structure
needed to implement Use-Case
 Analysis level sequence diagram has
been created to describe system
behavior needed to implement Use-Case

8. John Liebenau
Enterprise Architecture / Software Engineering
Described
 Story has been described in detail
 Acceptance criteria have been fully defined
 Story has been broken down into tasks
 Story has been estimated (detailed level)
 Must be in this state to be part of a Sprint Backlog
Story States
8
Identified
 Story has been briefly described
 Story has been prioritized
 Story has been estimated (high level)
 Must be in this state to be part of a Release Backlog
Implemented
 Story has been fully implemented
 Story has been tested and all acceptance criteria have
been verified
Fulfilled
 Implementation of Story has been demonstrated to
customer
 Customer has approved the implementation

9. John Liebenau
Enterprise Architecture / Software Engineering
Activities
9
Collect Requirements
Analyst
Business Requirement
Define/Refine Use-Case
Business Requirement
Use-Case Model Use-Case
Realize Use-Case
Analysis Model Use-Case Realization
Analyst
Developer
Use-Case
Define/Refine Story
Use-Case Use-Case Realization
Story Task List
Analyst
Tester
Define/Refine Test-Case
Use-Case
Test-Case Test Scenario
Story

10. John Liebenau
Enterprise Architecture / Software Engineering
Activities
10
Product Owner
Architecture Owner Define/Refine Architecture
Architecture Document
Architecture Owner
Product Owner
Use-Case Model Analysis Model

Manage Backlog
Story
Product Backlog
Product Backlog
Define/Refine Release Plan
Architecture Document
Product Backlog
Release Plan

11. John Liebenau
Enterprise Architecture / Software Engineering
Work Breakdown
11
Inception Stabilization Construction Transition
Release N
Scope Is Understood
• Understanding of what is to
be built in the release
 Key Requirements
 Use-Cases
 Story Backlog
• Understanding of the relative
priority of the requirements
and stories
• Agreement between customer
and development organization
on the scope of the release
and the overall timeline for
delivery
Architecture Is Stable
• Architecture has been
validated (by actual testing
and formal review) against the
key system requirements
• Risks have been sufficiently
mitigated in order to
predictably determine the cost
and schedule for completing
the development of the
system
Solution Is Constructed
• Functionality planned for
release has been
implemented
• Quality of the releases are
sufficient to deploy to QA for
regression , functionality,
performance testing, and user
acceptance testing
Solution Is Deployed
• System has passed all testing
• Supporting documentation
such as user guide and
operations support guide has
been created
• Release materials have been
packaged and deployed into
production environment
• Operational system has been
validated in production
Release Planning Meeting Alpha Release Beta Release
(Code Freeze)
Key
Release
Phase
Sprint
Milestone
Prod Release

12. John Liebenau
Enterprise Architecture / Software Engineering
Minimize Branching (with feature toggles)
12
Rel-1.0.0
Feature A On
Feature B Off
Feature C Off (partially implemented)
Rel-1.1.0
Feature A On
Feature B On
Feature C Off (partially implemented)
Rel-1.2.0
Feature A On
Feature B On
Feature C On
Dev
Rel-1.0.0 Rel-1.1.0
Rel-1.0.1 Rel-1.0.2 Rel-1.1.1
Rel-1.2.0
Feature Toggle
A technique where partially implemented features are hidden from users (effectively turned off) by means of a configuration mechanism.
Feature toggles eliminate (or minimize) the need for feature branching and enable software to be worked on as a unified codebase.
See: http://martinfowler.com/bliki/FeatureToggle.html for more information.

13. John Liebenau
Enterprise Architecture / Software Engineering
Templates & Examples
Templates
• http://teams/sites/fi/oms/Lists/SharedDocuments/DevelopmentMethod/Templates/
Examples
• http://teams/sites/fi/oms/Lists/SharedDocuments/DevelopmentMethod/Examples/
Presentation
• http://teams/sites/fi/oms/Lists/SharedDocuments/AgileDeliveryMethod.pptx
13

14. John Liebenau
Enterprise Architecture / Software Engineering
Appendix
14

15. John Liebenau
Enterprise Architecture / Software Engineering
Work Products
15
Work Products Description Produced By Related Activity
Business Requirement List Textual descriptions of functional and non-functional requirements primarily
derived through discussions with Customers, Users, or Domain Experts.
Analyst Collect Requirements
Use-Case Model Contains the use-cases of the application that provides a model of the
application’s intended functions and environment.
Analyst Define/Refine Use-Cases
Use-Case Document Textual description of a use-case that specifies the interactions between
actors and the system and organizes them into primary and alternative flows.
Analyst Define/Refine Use-Cases
Test-Case Document Textual description of the test-cases that verify the behavior of the system
based on a use-case and its constituent stories.
Tester Define/Refine Test-Cases
Analyst
Analysis Model Contains use-case realizations (class and sequence diagrams) that illustrate
the inner working of use-cases at a high level of abstraction.
Developer Realize Use-Case
Analyst
Use-Case Realization Describes the structural aspects (analysis class diagrams) and behavioral
aspects (communication or sequence diagrams) of the realization of a use-
case.
Developer Realize Use-Case
Analyst
Story Describes one flow of a use-case narrative in language that is understood by
all stakeholders. Special requirements and acceptance criteria are also
documented.
Analyst Define/Refine Stories
Developer
Product Backlog Prioritized collection of stories. Product Owner Manage Product Backlog
Application Model Set A set of models (use-case model, analysis model, design model, …) used to
visualize, specify, construct, and document—in detail—the architecture of a
application system.
Architecture Owner Define/Refine Architecture
Application Architecture Document Presents architecturally significant elements, relationships, and collaborations
from the system’s model set and the rationale for their design.
Architecture Owner Define/Refine Architecture
Release Plan Documents: the total story points planned for release, the team’s current
velocity, a velocity-based release calendar, and an initial mapping of stories
to sprints.
Produce Owner Define/Refine Release Plan
Architecture Owner
Sprint Backlog Set of stories allocated to a specific sprint. Scrum Master Define Sprint Plan
Consumable Solution A version of the application system that can—potentially—be consumed by
end users.
Team Realize Story
Sprint Retrospective Report Documents the results of a sprint and captures what went well, what did not
go well, and what to do to make things better.
Team Review Sprint Results

16. John Liebenau
Enterprise Architecture / Software Engineering
Activities
16
Activity Description Performed By Related Work Products
Collect Requirements Analyst identifies and documents requirements derived from
communication with Stakeholders such as Customer, User, and Domain
Expert
Analyst Business Requirement List
Define/Refine Use-Cases Analyst maps requirements to a set of use-cases that are formally
defined through a use-case model and use-case document
Analyst Use-Case Model
Use-Case Document
Define/Refine Test-Cases Tester collaborates with Analyst to understand use-cases and define
corresponding test-cases.
Tester Test-Case Document
Analyst
Realize Use-Case Developer collaborates with Analyst to understand a use-case and derive
an analysis model of class and sequence diagrams that describe (at a
high level) how the use-case will be implemented
Developer Analysis Model
Analyst Use-Case Realization
Define/Refine Stories Analyst and Developer collaborate to define the set of stories that
describe the various features or “slices” through a use-case in terms that
is understood by both Developers and Customers
Analyst Story
Developer
Manage Product Backlog Product Owner organizes stories into a product backlog and determines
story priorities by consulting with Customer and Developer
Product Owner Product Backlog
Define/Refine Architecture Architecture Owner organizes various models (use-case model, analysis
model, design model, deployment model, etc.) into an application model
set and then extracts the most architecturally significant elements into an
application architecture document for review with Technical Stakeholders
Architecture Owner Application Model Set
Application Architecture Document
Define/Refine Release Plan Product Owner and Architecture Owner collaborate to map stories from
the product backlog to a sequence of sprints that will culminate in a
release
Product Owner Release Plan
Architecture Owner
Define Sprint Plan Scrum Master assembles the sprint backlog from the release plan and
current product backlog and facilitates Team Members signing up to work
on stories
Scrum Master Sprint Backlog
Realize Story Team Members work together to complete the tasks that implement and
test a story
Team Members Consumable Solution
Review Sprint Results Team Members review the results of the previous sprint and capture
what worked, what did not work, what could be done better.
Team Members Sprint Retrospective Report

17. John Liebenau
Enterprise Architecture / Software Engineering 17
Object-Oriented Analysis & Design Practices
Use-Case Realization
• Perform use-case realizations as a team
• Identify the encompassing use-case for each work item (story) under analysis
• Review the use-case (documentation and models)
• Identify the analysis classes (boundary, processor, entity) relevant to the use-case and stories:
─ Boundaries represent the system elements that interact with actors
─ Processors represent the system elements responsible for processing logic
─ Entities represent the system’s data
• Use analysis class diagram(s) to describe the structure of the use-case and stories
• Use sequence diagram(s) or state machine diagram(s) to describe the behavior of the use-case and stories
Domain Driven Design
• Create a common language between users, analysts, developers, and testers
• Organize system architecture into layers:
─ Interaction Layer – Responsible for interacting with the users of the system including: presenting information to the user and interpreting user commands.
─ Service Layer – Provides the contracts that represent the services offered by the system.
─ Integration Layer – Provides the mechanisms that enable integration between the system’s client and server components and with other systems.
─ Application Layer – Implements the contracts from the Service Layer by coordinating application activity of elements from the Service Layer and the Domain
Layer.
─ Domain Layer – Contains information about the domain. This is the heart of the business software. The state of business objects is held here. Persistence of the
business objects and possibly their state is delegated to the Platform layer.
─ Platform Layer – Provides a supporting library for all the other layers. It provides communication between layers, implements persistence for business objects,
contains supporting libraries for the Interaction Layer, etc.
• Consistently use appropriate design patterns
─ Model-View-Controller
─ Service
─ Transport Object
─ Entity
─ Value Object
─ Aggregate Root
─ Repository
─ Factory

18. John Liebenau
Enterprise Architecture / Software Engineering 18
Additional Information
Books
Use-Cases 2.0 • http://sharepoint/sites/crmc/fi/Architecture%20Workgroup/Document%20Library/RecommendedReading/UseCaseDrivenDevelopment/
Use-Case+2_0_Jan11.pdf
Use-Cases: Patterns and Blueprints • http://www.amazon.com/Use-Cases-Patterns-Blueprints-Software/dp/0131451340
Unified Modeling Language User Guide • http://www.amazon.com/Unified-Modeling-Language-Guide-Edition/dp/0321267974
Object-Oriented Analysis & Design • http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-Edition/dp/020189551X
Design Patterns • http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
• http://sharepoint/sites/crmc/fi/Architecture%20Workgroup/Document%20Library/Patterns/DesignPatternsBook/contfso.htm
Domain-Driven Design • http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
POJOs in Action • http://www.amazon.com/POJOs-Action-Developing-Applications-Lightweight/dp/1932394583
Patterns of Enterprise App Architecture • http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420
Refactoring • http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672
Refactoring to Patterns • http://www.amazon.com/Refactoring-Patterns-Joshua-Kerievsky/dp/0321213351
Refactoring Databases • http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515
Continuous Delivery • http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
Designing Interfaces • http://www.amazon.com/Designing-Interfaces-Jenifer-Tidwell/dp/1449379702
Performance Solutions • http://www.amazon.com/Performance-Solutions-Practical-Creating-Responsive/dp/0201722291
Effective C# • http://www.amazon.com/Effective-Covers-4-0-Specific-Development/dp/0321658701
Effective Java • http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683

19. John Liebenau
Enterprise Architecture / Software Engineering 19
Additional Information
Articles
Feature Toggle • http://martinfowler.com/bliki/FeatureToggle.html
Object-Oriented Design Principles • http://www.objectmentor.com/omSolutions/oops_what.html
• http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign
Analysis Patterns • http://martinfowler.com/articles.html#ap
Domain Driven Design • http://sharepoint/sites/crmc/fi/Architecture%20Workgroup/Document%20Library/RecommendedReading/DomainDrivenDesignQuickly
.pdf
Continuous Delivery • http://martinfowler.com/articles/continuousIntegration.html
Use-Case Driven Development • http://www.ibm.com/developerworks/rational/library/5383.html
• http://www.ibm.com/developerworks/rational/library/content/RationalEdge/aug04/5670.html
• http://www.in2grateit.com/documents/RequirementsDevelopment-5.pdf
Web-Sites
Disciplined Agile Delivery • http://disciplinedagiledelivery.com/
Agile Modeling • http://www.agilemodeling.com
Design Patterns • http://hillside.net
Domain Driven Design • http://domaindrivendesign.org
Enterprise Integration Patterns • http://www.eaipatterns.com
Use-Case Driven Development • http://www.ivarjacobson.com/Use_Case_Driven_Development
Refactoring • http://refactoring.com
• http://industriallogic.com/xp/refactoring/catalog.html
• http://databaserefactoring.com
Continuous Delivery • http://continuousdelivery.com
User Interface Patterns • http://ui-patterns.com
• http://developer.yahoo.com/ypatterns