Webster VisualizeWebster VisualizeWebster Financial

Team Visual Scrumware

Joe AndrusyszynMark Bryant

Brian HannanRobert Songer

OutlineOutline

Overview Process Requirements Design Testing Risks Schedule Metrics Reflections

Overview – The ProblemOverview – The Problem

Webster Financial employs a XML-based automated testing strategy

Test case logic comes from business analysts

XML test cases written by development team

Webster needs to bridge the gap

Overview – The SolutionOverview – The Solution

Flowchart application inspired by Microsoft Visio

ProcessProcess

Structured Scrum– Process Constraints

• Webster Financial is very structured• Forced to create SRS up front

– Scrum• Initially, system needs were not clear• Low process overhead• No project leader• Works well for small groups• Flexibility for UI development

Process ActivitiesProcess Activities

Weekly Telephone Meetings w/ ClientScrum Meetings – 3 times per week

Weekly Project MeetingsSprint Backlog (activity schedule)

Sprint Burndown Charts

Requirements ProcessRequirements Process

Elicitation– Teleconferencing– Throwaway Prototypes

Negotiation Multiple SRS Revisions

– Client reviews– Revisions based on reviews

Final SRS– Sign off by client– Not expected to change

RequirementsRequirements

Validation– GUI prototypes given to client– Technology Prototypes

Acceptance Testing– UAT Plan based off the SRS

Future Management– Evolutionary & Throwaway Prototyping

RequirementsRequirements

DesignDesign

Incremental.NET 2.0 Framework

– XML & GUIDiagrams

– State– Sequence– XSD organization

Current Status

TestingTesting

Acceptance– Created from SRS– Handed over to client

Unit– Automation w/ NUnit

System IntegrationRegressionTracking with Bugzilla

RisksRisks

Risk ID Number

Risk DescriptionImpact Rating

Probability of Occurrence

Weighted Impact Rating

1Team members are taking other classes which could cause some deliverables to be late or of lesser quality

8.00 80% 64.00

2Team members' focus is on things other than required deliverables, causing the team to be late or miss key deliverables

9.00 60% 54.00

3The team does not understand the full needs and desires of the customer.

10.00 50% 50.00

Risk MitigationRisk Mitigation

Strategies for Top 3 Risks– Allocate work around class schedules– Prioritize tasks in sprint planning– Throwaway prototyping on top of

evolutionary systemSuccessfully Mitigated

– Requirements Creep– Lack of C# knowledge

ScheduleSchedule

Monthly SprintsFive Product Releases

– one or two per sprintSprint ScheduleCurrent Status

Sprint Schedule - ExampleSprint Schedule - ExampleSprint MonthSprint Month FebruaryFebruary

Sprint ThemeSprint ThemeOperational Prototyping, Test Planning & Operational Prototyping, Test Planning &

DesignDesign

# Activity Level 1Activity Level 2

Activity Level 3

Assigned To

Activity Start Date

Activity End Date

Estimated Work Hours

Actual Work Hours

Estimated %

Complete

Estimated Hours

RemainingComments

1 Requirements    Brian, Rob, Joe, Mark

    30 32.5 100% 0  

1.1  Finish Finish

ElicitationElicitation  

Brian, Rob, Brian, Rob, Joe, MarkJoe, Mark

2/1/20082/1/2008 2/12/20082/12/2008 5.55.5 6.56.5 100%100% 00

Elicitation may still need to be Elicitation may still need to be done as we develop the done as we develop the

features that didn’t have many features that didn’t have many requirements up front.requirements up front.

1.11    client client phone phone

meetingsmeetings

Brian, Rob, Brian, Rob, Joe, MarkJoe, Mark

2/1/20082/1/2008 2/29/20082/29/2008 66 1010 100%100% 00

We will not need to have client We will not need to have client phone meetings for phone meetings for

requirements anymore. The requirements anymore. The rest will be taken care of rest will be taken care of

through emails. through emails.

1.12    client client emailsemails

RobRob 2/1/20082/1/2008 2/29/20082/29/2008 44 44 100%100% 00

Emails should hopefully Emails should hopefully increase from the normal due increase from the normal due to not having phone meetings to not having phone meetings

with the client.with the client.

1.2  

Complete Complete Baseline Baseline

SRS SRS DocumentDocument

  Brian, Rob, Brian, Rob, Joe, MarkJoe, Mark

2/1/20082/1/2008 2/12/20082/12/2008 14.514.5 1212 100%100% 00Estimate extended as more Estimate extended as more

work was neededwork was needed

Sprint OrganizationSprint Organization

MetricsMetrics

Estimation AccuracyDefects

– Per Release– Per Module

Time Spent Per Module

Effort EstimationEffort Estimation

Estimation Accuracy

0

50

100

150

200

250

Week 4 Week 5 Week 6 Week 7 Week 8 Week 9

Week

Per

cen

tag

e o

f E

stim

ate

Actual Ideal

ReflectionsReflections

Current Project StatusPositive

– Relatively on schedule– Under budget

• Removal of Oracle Database requirements– No need for XML interpreter– No interaction with Webster libraries needed– Saves Webster lots of money for a test harness

– Well-defined scope & SRS

ReflectionsReflections

Negative– SRS completed late

• Design pushed back

– Slow start• Five weeks of foggy ideas about system

– Little face-to-face interaction w/ client

Heading Into SpringHeading Into Spring

Continue Design– UI research and exploration

Incremental ImplementationIntegrate Test PlanProduct Releases

Webster VisualizeWebster Visualize

Webster FinancialTeam Visual Scrumware

Joe AndrusyszynMark Bryant

Brian HannanRobert Songer