Front Cover -- Agile Data Warehousing Project Management -- Copyright Page -- Contents -- List of Figures -- List of Tables -- Preface -- Answering the skeptics -- Intended audience -- Parts and chapters of the book -- Invitation to join the agile warehousing community -- Author's Bio -- An Introduction to Iterative Development -- What Is Agile Data Warehousing? -- A quick peek at an agile method -- The "disappointment cycle" of many traditional projects -- The waterfall method was, in fact, a mistake -- Agile's iterative and incremental delivery alternative -- Agile as an answer to waterfall's problems -- Increments of small scope -- Business centric -- Colocation -- Self-organized teams -- Just in time -- 80-20 Specifications -- Fail fast and fix quickly -- Integrated quality assurance -- Agile methods provide better results -- Agile for data warehousing -- Data warehousing entails a "breadth of complexity" -- Adapted scrum handles the breadth of data warehousing well -- Managing data warehousing's "depth of complexity" -- Guide to this book and other materials -- Simplified treatment of data architecture for book 1 -- Companion web site -- Where to be cautious with agile data warehousing -- Summary -- Iterative Development in a Nutshell -- Starter concepts -- Three nested cycles -- The release cycle -- Development and daily cycles -- Shippable code and the definition of done -- Time-boxed development -- Caves and commons -- Product owners and scrum masters -- Product owner -- Scrum master -- Developers as "generalizing specialists" -- Improved role for the project manager -- Might a project manager serve as a scrum master? -- User stories and backlogs -- Estimating user stories in story points -- Iteration phase 1: story conferences -- Iteration phase 2: task planning -- Basis of estimate cards to escape repeating hard thinking.

Task planning doublechecks story planning -- Iteration phase 3: development phase -- Self-organization -- Daily scrums -- Accelerated programming -- Test-driven development -- Architectural compliance and "tech debt" -- Iteration phase 4: user demo -- Iteration phase 5: sprint retrospectives -- Retrospectives are vital -- Close collaboration is essential -- Selecting the optimal iteration length -- Nonstandard sprints -- Sprint 0 -- Architectural sprints -- Implementation sprints -- "Spikes" -- "Hardening" sprints -- Where did scrum come from? -- Distant history -- Scrum emerges -- Summary -- Streamlining Project Management -- Highly transparent task boards -- Task boards amplify project quality -- Task boards naturally integrate team efforts -- Scrum masters must monitor the task board -- Burndown charts reveal the team aggregate progress -- Detecting trouble with burndown charts -- Developers are not the burndown chart's victims -- Calculating velocity from burndown charts -- Common variations on burndown charts -- Setting capacity when the team delivers early -- Managing tech debt -- Managing miditeration scope creep -- Diagnosing problems with burndown chart patterns -- An early hill to climb -- Shallow glide paths -- Persistent inflation -- Should you extend a sprint if running late? -- Extending iterations is generally a bad idea -- Two instances where a changing time box might help -- Should teams track actual hours during a sprint? -- Eliminating hour estimation altogether -- Managing geographically distributed teams -- Consider whether fully capable subteams are possible -- Visualize the problem in terms of communication -- Choose geographical divisions to minimize the challenge -- Invest in a solid -- Provide repeated booster shots of colocation for individuals -- Invest in high-quality telepresence equipment -- Provide agile team groupware.

Summary -- Defining Data Warehousing Projects for Iterative Development -- Authoring Better User Stories -- Traditional requirements gathering and its discontents -- Big, careful requirements not a solution -- A step in the right direction -- Agile's idea of "user stories" -- Advantages of user stories -- Identifying rather than documenting the requirements -- User story definition fundamentals -- Quick test for actionable user stories -- How small is small? -- Epics, themes, and stories -- Common techniques for writing good user stories -- Keep story writing simple -- Use stories to manage uncertainty -- Reverse story components -- Focus on understanding "who" -- Focus on understanding "what" -- Focus on understanding "why" -- Be wary of the remaining w's -- Add acceptance criteria to the story-writing conversations -- Summary -- Deriving Initial Project Backlogs -- Value of the initial backlog -- Sketch of the sample project -- Fitting initial backlog work into a release cycle -- The handoff between enterprise and project architects -- Key observations -- User role modeling results -- Key persona definitions -- Carla in corp strategy -- Franklin in finance -- An example of an initial backlog interview -- Framing the project -- Finance is upstream -- Finance categorizes source data -- Customer segmentation -- Consolidated product hierarchies -- Sales channel -- Unit reporting -- Geographies -- Product usage -- Observations regarding initial backlog sessions -- Sometimes a lengthy process -- Detecting backlog components -- Managing user story components on the backlog -- Prioritizing stories -- Summary -- Developer Stories for Data Integration -- Why developer stories are needed -- Introducing the "developer story" -- Format of the developer story -- Developer stories in the agile requirements management scheme.

Agile purists do not like developer stories -- Initial developer story workshops -- Developers workshop within software engineering cycles -- Data warehousing/business intelligence reference data architecture -- Forming backlogs with developer stories -- Evaluating good developer stories: DILBERT'S test -- Demonstrable -- Independent -- Layered -- Business valued -- Estimable -- Refinable -- Testable -- Small -- Secondary techniques when developer stories are still too large -- Decomposition by rows -- Decomposition by column sets -- Decomposition by column type -- Decomposition by tables -- Theoretical advantages of "small" -- Summary -- Estimating and Segmenting Projects -- Failure of traditional estimation techniques -- Traditional estimating strategies -- Why waterfall teams underestimate -- A single-pass effort -- Insufficient feedback -- Overoptimism rewarded -- Few reality checks -- Criteria for a better estimating approach -- An agile estimation approach -- Estimating within the iteration -- Estimating the overall project -- Quick story points via "estimation poker" -- Story points and ideal time -- Story points defined -- Ideal time defined -- The advantage of story points -- Estimation accuracy as an indicator of team performance -- Value pointing user stories -- Packaging stories into iterations and project plans -- Criteria for better story prioritization -- Segmenting projects into business-valued releases -- The data architectural process supporting project segmentation -- Artifacts employed for project segmentation -- Business target model -- Dimensional model -- Star schema -- Tiered integration model -- Categorized service model -- Project Segmentation technique 1: dividing the star schema -- Project Segmentation technique 2: dividing the tiered integration model.

Project Segmentation technique 3: grouping waypoints on the categorized services model -- Embracing rework when it pays -- Summary -- Adapting Iterative Development for Data Warehousing Projects -- Adapting Agile for Data Warehousing -- The context as development begins -- Data warehousing/business intelligence-specific team roles -- Project architect -- Data architect -- Systems analyst -- Systems tester -- The leadership subteam -- Resident and visiting "resources" -- New agile characteristics required -- Avoiding data churn within sprints -- Pipeline delivery for a sustainable pace -- New meaning for Iteration 0 and Iteration -- 1 -- Pipeline requires two-step user demos -- Keeping pipelines from delaying defect correction -- Resolving pipelining's task board issues -- Pipelining as a buffer-based process -- Pipelining is controversial -- Continuous and automated integration testing -- High quality is a necessity -- Agile warehousing testing requirements -- Nominal data testing -- Incoherent data -- Missing data -- Dirty data -- Multiple time points -- The need for automation -- Requirements for a warehouse test engine -- Automated testing for front-end applications -- Evolutionary target schemas-the hard way -- Summary -- Starting and Scaling Agile Data Warehousing -- Starting a scrum team -- Stage 1: time box and story points -- Stage 2: pipelined delivery -- Stage 3: developer stories and current estimates -- Stage 4: managed development data and test-driven development -- Stage 5: automatic and continuous integration testing -- Stage 6: pull-based collaboration -- Scaling agile -- Application complexity -- Geographical distribution -- Team size -- Compliance requirements -- Information technology governance -- Organizational culture -- Organizational distribution -- Coordinating multiple scrum teams -- Coordinating through scrum of scrums.

Matching milestones.