List of Figures

Figure 1.1 Structure of Scrum development iteration and duration of its phases.
Figure 1.2 All too often, waterfall methods yield to the project “disappointment cycle.”
Figure 1.3 Complex data integration requires increasing modifications to generic agile methods.
Figure 1.4 An agile perspective on the competing risks for DWBI projects.
Figure 1.5 High-level structure of this book and its companion volume.
Figure 2.1 Typical waterfall method with key project management artifacts indicated.
Figure 2.2 Three cycles of generic Scrum.
Figure 2.3 Estimating story points.
Figure 2.4 Identifying an iteration’s “commit line” during sprint planning.
Figure 2.5 Common project room pattern for accelerated coding—Part 1.
Figure 2.6 Common project room pattern for accelerated coding—Part 2.
Figure 2.7 Handling accepted and rejected user stories.
Figure 2.8 Identifying areas of improvement during the sprint retrospective (Part 1).
Figure 2.9 Identifying areas of improvement during the sprint retrospective (Part 2).
Figure 3.1 Simplified representation of a Scrum task board in midsprint.
Figure 3.2 Typical agile burndown chart with a perfect line.
Figure 3.3 Midsprint burndown chart showing trouble.
Figure 3.4 End-of-sprint burndown chart showing a delivery gap.
Figure 3.5 Calculating labor-hour velocity using a burndown chart.
Figure 3.6 Burndown chart showing tech debt and scope creep.
Figure 3.7 Calculating labor-hour velocity for sprints with scope creep.
Figure 3.8 Common burndown patterns: The shallow glide.
Figure 3.9 Worrisome burndown chart pattern: Persistent inflation.
Figure 3.10 Impact of distributing teammates is measurable.
Figure 3.11 Geographical distribution’s impact on team communications.
Figure 3.12 Good remote-presence tools help distributed teams.
Figure 4.1 Agile’s three levels of requirements management.
Figure 4.2 Sample vision box for a revenue assurance project.
Figure 4.3 Sample product board.
Figure 4.4 Three levels of user goals.
Figure 5.1 Fitting early iterations into a typical PMO release cycle.
Figure 5.2 Starter business target model for sample project.
Figure 5.3 User role models for the sample data mart project.
Figure 5.4 Business target model at end of sample project’s initial backlog interview.
Figure 5.5 General functions of backlog items in data integration projects.
Figure 6.1 Most data integration stories cannot be delivered with only one sprint.
Figure 6.2 Hierarchy for agile project definition objects for data integration work.
Figure 6.3 Defining work units for an agile data warehousing project.
Figure 6.4 Developer stories derived from the sample user story.
Figure 6.5 Deriving DILBERT’S test from the user story INVEST test.
Figure 6.6 Developer stories by sets of rows.
Figure 6.7 Decomposing developer stories by sets of columns.
Figure 6.8 Different column types found in data warehousing tables.
Figure 6.9 Decomposing developer stories by target tables.
Figure 6.10 Consistent story size improves an agile team’s velocity.
Figure 7.1 Empirically, waterfall estimates are difficult to rely upon.
Figure 7.2 Two units of measure increase accuracy of agile estimates.
Figure 7.3 Typical card deck for agile “estimating poker.”
Figure 7.4 Deriving a current estimate from a project backlog.
Figure 7.5 Sample dimensional model and corresponding star schema.
Figure 7.6 Sample tiered data model for an integration layer (drawn schematically).
Figure 7.7 Front-end project categorized service model.
Figure 7.8 Back-end project categorized service model.
Figure 7.9 Project segmentation lines drawn on a star schema.
Figure 7.10 Project segmentation using a tiered integration data model.
Figure 7.11 Project segmentation lines on a back-end categorized service model.
Figure 8.1 Expanded team roles for agile data warehousing.
Figure 8.2 Data churn wastes agile team productivity.
Figure 8.3 Agile mash-ups that do not work.
Figure 8.4 Pipelined delivery technique.
Figure 8.5 Pipelined work stages across project iterations.
Figure 8.6 Disposition of defects depends on severity.
Figure 8.7 Using buffers to manage both ends of the pipeline.
Figure 8.8 Testing warehouse applications properly requires many data sets.
Figure 8.9 Warehouse test engines must iterate through numerous scenarios.
Figure 8.10 Extending back-end testing to cover most of a warehouse application.
Figure 9.1 Automated testing gives team in an incremental point of view.
Figure 9.2 Enterprise business intelligence architecture balancing framework.
Figure 9.3 Data topology diagram for typical warehouse program with extensively interdependent projects.
Figure 9.4 Specialty-based meta scrums coordinate projects across large programs.
Figure 9.5 Using current estimates for milestone planning between agile DWBI projects.
Figure 9.6 Typical earned-value reporting graph for a waterfall project.
Figure 9.7 Balancing work between teams using earned-value analysis.
Figure 9.8 One answer to “what is agile data warehousing?”
Figure 9.9 Tracking defects by iteration.
Figure 9.10 Burn-up chart showing value points delivered by sprint.
Figure 9.11 Single team’s story point distribution chart by work type.
Figure 9.12 Scrum data warehousing task board adapted for Kanban concepts.
Figure 9.13 Cumulative flow diagram and some of the metrics it provides.
Figure 9.14 Cycle time distribution analysis.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.209.121