OPIM 5668 Final Exam Study Set

User Roles

• The purpose of identifying user roles is to make sure that we think really hard about the users that we absolutely, positively must satisfy with the new system • We DON'T need user roles for every conceivable user of the system, but we need roles for the ones who can make or break the success of the project

User Story

one short sentence in the everyday language of the end user that states what a user does as part of his or her work They tell a short story about how the user, customer or other persona will use the system, and what benefit they derive from the functionality. The goal is to provide context, which helps the product owner effectively manage and rank the backlog

How to deal with defects (bugs)

questions to ask when approaching a bug in Agile projects: • Should they be placed on the product backlog or in a separate bug list? • If they're on the backlog, does the product owner get to set their priorities, or are they automatically the most important items? • Should there be a separate bug fixing iteration/sprint?

IRR (internal rate of return)

• IRR is a rate of return used in capital budgeting to measure and compare the profitability of investments • IRR consider interest rate of the investment; the higher IRR, the more profitable the project

Kanban with Work in Process (WIP)

• In Kanban the first step is to visualize your current process, just as it is, in order to see where the bottlenecks are. • Then you introduce WIP limits and start a path of evolution that may or may not modify or replace your current process over time. Kanban aims to control the amount of WIP that is allowed by limiting the number of slots available. This lets us limit the amount of WIP the team has

ROI (Return on Investment)

• Indicates financial return • ROI = (Projected Savings (benefits) - Costs) / Costs • A positive ROI means the project is profitable, higher the ROI, the better

Minimally Marketable Feature (MMF)

• MMF refers to the package of functionality that is complete enough to be useful to the users or market, yet small enough that it does not represent the entire project. • The smallest set of functionality that must be realized in order for the customer to perceive value. For web hosting company, for example, a minimally marketable feature could be a hosting feature that allows web pages and blog posts but the service would not need to have a social media integration, ad-word integration, or visitor tracking in its first release. Instead, these sets of functionality could be added in subsequent releases. (think like releasing a barebones game and adding DLC later on)

Acceptance Criteria

• Product owner writes acceptance criteria for every item prior to the sprint/iterative planning • During backlog refinement and/or sprint planning, acceptance criteria are discussed and negotiated with the development team • Define the boundaries for an item • Acceptance criteria are item-specific, while definition of done (DoD) works for all feature items in the product backlog.

Relative Prioritization / Ranking

• Relative weighting is a prioritization approach that considers both the positive benefit of the presence of a feature and the negative impact of its absence • Each theme or epic being considered for the next release is assessed in terms of the benefits it will bring if implemented and the penalty that will be incurred if it is not implemented

Definition of Done (DoD)

DoD is a comprehensive checklist of necessary, value-added activities that assert the quality of a feature and not the functionality of that feature. • DoD is an auditable checklist • DoD is not static. • Shared understanding among the team on what 'done' means

Definition of Ready (DoR)

DoR describes a state of product backlog items which they must be in order for them to be eligible for discussion on the sprint planning meeting Ready = Product Backlog item is made available and up for discussion by the product owner for the sprint planning meeting

Testers

Testers are one role in team delivering a quality product that drive business value. The whole team owns, and are jointly committed and accountable to quality

Kanban Model

The Kanban model is based on the notion that the team works on the appropriate number of features through completion. When the team is ready to begin on the next feature, they pull a feature from a small queue of potential work. This allows for proper management of both selecting what to work on and how to do the work.

Why Agile?

- Accelerate time to market - managing change priorities - better align IT/Business - Increase productivity - Project Visibility - Reduce Risk - Reduce Cost - Enhance software maintainability etc.

why is time-boxing important

- Establishes a WIP limit - Forces prioritization - Demonstrates Progress - Avoids Unnecessary perfectionism - Motivates closure - Improves predictability

Examples of Agile Practices

- Planning Poker - Self-organization - Team agreements - velocity - unit testing

Release Planning Key Players

- Scrum Master - facilitates the meeting - Product Owner - represents a general view of the product backlog - Delivery Team/Agile Team - provide insights into technical feasibility and dependencies - Stakeholders - act as trusted advisors as decisions are made around the release plan

Why WIP can be a problem

- WIP represents money invested with no return on that investment yet. - WIP hides bottlenecks in processes, and it masks efficiency issues. - WIP also represents a risk in the form of potential rework, since there may still be changes to items until those items have been accepted. If there is a large inventory of WIP, there may in turn be a lot of scrap or expensive rework if a change is required.

Agile Modeling

An Agile model is one that is minimally sufficient, it conveys just enough to be useful • Agile models are more effective than traditional models because they are just barely good enough, they don't have to be perfect.

Epic

An Epic is just a large user story

Kano Analysis

An analysis of product development and customer satisfaction based on needs fulfilled/not fulfilled vs. satisfaction/dissatisfaction. 4 main components: 1. Must haves are elements the product cannot ship without. 2. Dis-satisfiers are things the product must NOT include. 3. Satisfiers include requirements where the more you have the better the product is perceived. Like a marketing checklist, each feature adds incremental value. 4. Delighters take the product beyond simply meeting the requirements to boosting customer satisfaction and recommendation

User story template

As a <user role>, I want to/would like/should <activity> so that <business value>.

Properties of a good Backlog: DEEP

D - Detailed Appropriately - the product backlog items are detailed appropriately E - Estimated - the product backlog items are estimated E - Emergent - the product backlog has an organic quality P - Prioritized - all items in the product backlog are prioritized - in order to maximize the customer ROL

Daily Scrum

Daily meetings in which the team shares it's progress and commitments in the project. They may also adjust plans to remove impediments in these meetings. Typically no more than 15 minutes.

Factors in Backlog Prioritization

Dependencies Risk Cost Value Resources Knowledge

Challenges with Estimation

• Requirements are hard to estimate • Difficult to predict what exactly will be delivered, when • Estimating takes too long and we still don't get it right • Based on high-level estimates • Fixed scope, time, and budget • Estimates are provided by the wrong people (not the one doing actual work) • Software projects are unique and ambiguous; hard to provide exact estimates • Business promises unrealistic deadlines then tell the team to make it work

Scrum and Iterations

• Scrum attempts to build a potentially shippable (properly tested) product increment every iteration. • Scrum uses fixed-length iterations, called sprints, which are typically 2-4 weeks long.

NPV (net present value)

• The net future cash flow (profit - expenditure) in terms of today's value (adjusted for future inflation, etc.) • A positive NPV means the project is profitable. Higher NPV is better

What is Agile

Agile is an approach of building products or services by EMPOWERING and TRUSTING people, acknowledging CHANGE AS A NORM, and promoting CONSTANT FEEDBACK.

Agile is a Philosophy

Agile is a PHILOSOPHY that uses organizational models based on people, collaboration and shared values. Agile uses rolling wave planning; iterative and incremental delivery; rapid and flexible response to change; and open communication between teams, stakeholders, and customers.

5 Core Principles of Kanban

1, Visualize the workflow 2. Limit work in progress 3. Make process policies explicit 4. Manage flow 5. Improve Collaboratively

User Stories: the 3 C's

1. Card- the card is an overview of the who, what, and why of a user story 2. Conversation - the card provides the basis for a conversation between the product owner or customer and the delivery team 3. Confirmation - the results of the conversation should be captured as acceptance criteria. A well-defined user story is testable. How will the product owner confirm that the story was implemented properly?

Sprint Planning Steps

1. Determine capacity (number of ideal hours in a sprint, days each team member available, and percentage of time each member commit). 2. Product owner describe the backlog item. 3. The team determines completion task for that item. 4. Team members volunteer to own the task. 5. Task owners estimate the ideal hours they need to finish their task. 6. Planning continues until the team reaches capacity.

4 stages of ATDD cycle

1. Discuss - Work with business stakeholders to understand their real need and concerns 2. Distill - Distill requirements into a set of acceptance tests 3. Develop - Write the code to implement the requested feature using test-driven development (TDD) 4. Demonstrate - Show the business stakeholders the new feature in the emerging system and request feedback

Agile Manifesto Values

1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan

8 steps to Relative Prioritization

1. List All of the Requirements 2. Estimate the Relative Benefit 3. Estimate the Relative Penalty 4. The Total Value Column 5. Estimate the Relative Cost 6. Estimate the Relative Degree 7. Calculate Priority Number 8. Sort the List of Features

Agile Manifesto Principles

1. Our highest priority is to satisfy the customer through 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 for 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 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. 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.

Scrum Cycle Summary

1. Product owner updates the requirements in the prioritized list, called product backlog 2 .The product owner and development team get together for the sprint planning meeting and generate the sprint backlog. What will be done and how it will be done in this development cycle(Sprint) 3. The development team does the development work of the product increment that has been planned, aiming to meet the Sprint goals 4. Every day, the development team holds the daily scrum, a 15-minute meeting which aims to promote visibility and communication between team members. 5. At the end of the development cycle, the development team will have produced a product increment which is done, meaning value for the customer. 6. Then the development team meets the product owner and stakeholder for the sprint review and presents to them what was produced during the sprint 7. Right after the review meeting, the Scrum team holds the sprint retrospective, where it discusses what happened and what could be improved for future sprints. 8. And a new cycle starts until the final product is produced/project complete.

Value Based Decision Making techniques

1. ROI/NPV/IRR 2. Compliance 3. Customer valued prioritization 4. Minimum viable product 5. Minimum marketable feature 6. Relative prioritization ranking 7. Moscow 8. Kano analysis

Affinity Estimating steps

1. Silent relative sizing - In this step, the team first defines simple guidelines which may help them in performing a relative sizing exercise 2. Editing the wall - In this step, team members read the product backlog item, discusses and allows moving items around as needed in either direction. 3. Place items into relative sizing buckets - place each item in into a sizable bucket. Place the stories to indicate the complexity 4. Product owner "challenge" - Product owner may request estimate clarification, and if required, a re-size and re-order of the stories. 5. Document the Estimates - In this last step, the team documents the discussed estimate and saves it for future use.

Iteration Planning steps

1. The product owner describes the highest ranked product backlog item 2. The team determines the tasks necessary to complete that product backlog item 3. Team members volunteer to own the tasks 4. Task owners estimate the ideal hours they need to finish their task 5. Planning continues while the team can commit to delivery without exceeding capacity

3 Scrum pillars

1. Transparency 2. Inspection 3. Adaptation

three questions to be addressed in the daily scrum

1. What has been accomplished since the last meeting? 2. What will be done before the next meeting? 3. What obstacles are in the way?

User Persona

A Persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design • Personas are a representative behavior and activity profile for a customer base • Personas are contextual and specific to the particular application or service

Product Vision

A document that describes what the product is, who will use the product, why the product will be used, and how the product supports the strategy of a company. The vision statement is concise wording of the project goals to help members pass the elevator test (be able to explain in 2 min)

Agile Manifesto

A mindset that consists of 4 main values and 12 different principles

Scrum Roles: Scrum Master

A person who ensures that the team is productive, facilitates the daily Scrum, enables close cooperation across all roles and functions, and removes barriers that prevent the team from being effective Ensures that the value, practices and rules of Scrum are understood and followed.

Theme

A theme is a collection of similar stories

Wireframes

A wireframe is a "low fidelity" prototype. This non-graphical artifact shows the skeleton of a screen, representing its structure and basic layout. It contains and localizes contents, features, navigation tools and interactions available to the user. • The purpose is to help clarify what "done" looks like and validate the teams approach before they commit to it.

Accuracy vs Precision

Accuracy is more important than precision. It is better to be roughly right than precisely wrong

Scrum Roles: Development Team

Generates value for the customer, building high quality product increments. •Self-organizing, self-managing •Negotiates commitments with the product owner •Intensely collaborative •Develops the product •Cross-functional •Organizes work •Reports progress •Continuously improves

Wideband Delphi

Group-based estimation method for estimating the efforts Steps: - Moderator reads the story and reviews the functionality - Estimators are allowed to ask any questions and then they go away and estimate their story in private - Moderator consolidates the estimates - Review and team discussion on variations - Repeat the process until consensus is reached

Ordering the Backlog

Higher Priority - developed sooner - fined grained, more detailed Lower Priority - developed later coarse grained, less detailed

Attribute of good User Stories: INVEST

I - Independent - •As much as possible, care should be taken to avoid introducing dependencies between stories. Dependencies between stories lead to prioritization and planning problems. N - Negotiable - Stories are negotiable. They are not written contracts or requirements that the software must implement. V - Valuable - A story needs to be valuable to the customer E - Estimable - A good story can be estimated. We do not need an exact estimate, but just enough to help the customer rank and schedule the story's implementation. S - Small - Good stories tent to be small T - Testable - A good story is testable. Writing a story card carries an implicit promise: "I understand what I want well enough that I could write a test for it."

Test-driven development (TDD)

In TDD, a programmer writes a test before they write any code. The test fails and the programmer writes just enough code to make it pass. This cycle is repeated on timelines of every few minutes.

Minimal Viable Product (MVP)

In product development, the minimum viable product (MVP) is the product with the highest return on investment versus risk. • A minimum viable product has just those core features that allow the product to be deployed, and no more • It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent

The purpose of the Sprint Retrospective

Inspect how the last Sprint went with regards to people, relationships, process, and tools; • Identify and order the major items that went well and potential improvements; and, • Create a plan for implementing improvements to the way the Scrum Team does its work

Kanban vs Scrum

Kanban is flow based and Scrum is an example of time-boxing

Absolute vs Relative Estimating

Relative Estimating - focuses on size and complexity - this happens at the story level Absolute Estimating - focuses on ideal times - this happens at the task level

Scripted testing vs Exploratory testing

Scripted - tests are first designed and recorded. Then they may be executed at some time later or by a different tester Exploratory - tests are designed and executed at the same time, and they are often not recorded

What is Scrum?

Scrum is the most common Agile Method • The Scrum framework consists of Scrum teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum's success and usage. • A framework within which people can address complex problems, while productively and creatively delivering product of highest possible value.

Effective testing on Agile projects

Sometimes there is a need to do individual testing, but agile testing is mostly collaborative. Work with others to achieve your goal

T-shirt sizing

T-shirt sizing is a project estimation and capacity planning tool that helps you track how much time or effort an initiative will take. To do this, you assign each project or task a t-shirt size—from Extra Small to XXL—to represent that task's relative effort. Depending on how you choose to use this tool, a t-shirt size can represent task scope, effort, complexity, work hours, time estimates—or all of the above.

Agile Project Charter

no different from a normal project charter - no more than a page long - provides a clear definition of what success looks like for the project - has 3 primary components 1. vision 2. mission 3. success criteria

Scrum Roles: Product Owner

The person responsible for the business value of the project and for deciding what work to do and in what order, as documented in the product backlog. Ensure and maximized the ROI for the customer from the work of the Team.

Product Backlog Grooming

The process of adding details, estimates, and ordering the items in the product backlog - this is an ongoing process and usually consumes no more than 10% of the capacity of the development team

Product Backlog

The product backlog is the cumulative list of desired deliverables for the product. This includes features, bug fixes, documentation changes, and anything else that might be meaningful and valuable to produce - the items in the backlog are ranked and ordered from high priority to low priority

Time-Box and Scrum

Time-boxing is designed to establish a sense of urgency and to coerce the team to focus their efforts on getting something done. Scrum, rooted in the concept of time-boxing, is a time-management technique that helps organize the performance of work and manage scope. Each event takes place in a time frame with a specific start and end, called a time-box

Traditional vs Agile testing

Traditional: - Change - manage and control it - Planning - comprehensive up front test design - Documentation - verbose - Handoffs - formal entrance and exit criteria with sign-offs - Automation - system level built by tools specialists, created after the code is 'done' Agile - Change - accept it - Planning - do it as you go - Documentation - only as much as absolutely necessary - Handoffs - it's not a relay race... collaborate - Automation - all levels, built by anyone, an integral part of the project

Traditional vs Agile

Traditional: - defined process: control and coordinated - work is organized around the team - plan all in advance - gantt chart Agile: - empirical process: inspect and adapt - team organize around work - plan as you go - user stories

Value delivery: Traditional vs Agile Value Delivery

Traditional: risk of failure increases over time and the value delivery happens once at the end of the project Agile: Risk of failure decreases over time and value delivery happens multiple times and goes up over time

Multiple levels of planning (planning onion)

Vision Roadmap Release Iteration Daily Release planning - Release planning considers the user stories or themes that will be developed for a new release of a product or system. The goal of release planning is to determine the appropriate answer to the questions of scope, schedule, and resources for a project. Release planning occurs at the start of the project but is not an isolated effort. A good release plan is updated throughout the project (usually at the start of each iteration) so that it always reflects the current expectations about what will be included in the release. Iteration planning - conducted at the start of each iteration. Based on the work accomplished in the just-finished iteration, the product owner identifies high-priority work the team should address in the new iteration. Because we are looking at a closer horizon than with release planning, the components of the iteration plan can be smaller. During iteration planning, we talk about the tasks that will be needed to transform a feature request into working and tested software. Daily planning - During their daily meetings, teams constrain the planning horizon to be no further away than the next day, when they will meet again. Because of this, they focus on the planning of tasks and on coordinating the individual activities that lead up to the completion of a task.

What, Who, and How do we Estimate

What do we estimate? - Stories (single unit of business functionality) Who estimates? - the development team How do we estimate? - Relative sizing / story points - ideal time - affinity estimating - wideband delphi (planning poker)

The Cone of Uncertainty

describes the amount of uncertainty during a project. At the beginning of a project, it's hard to estimate because of little in known about the product or the results. As you begin researching and developing the product, the uncertainty level will decrease and eventually reach zero percent, typically at the end of a project

Exploratory testing

learning about the system while also designing and executing tests, using feedback from the last test to inform the next - emphasizes the personal freedom and responsibility of the individual tester

Product Increment

the sum of all the Product Backlog items completed during a Sprint and all previous Sprints At the end of a sprint, the new increment must be "done," which means it must be in useable condition and meet the Scrum team's definition of "done." It must be in useable condition regardless of whether the product owner decides to actually release it.

Visualize the Workflow

visualize with a kanban board (multiple columns with cards in them) - move cards from left to right as the card gets more work done on it (work in progress to done)

Agile testing main ideology

we go from testing last to test driven (test as you go!)

Acceptance Test Driven Development

• ATDD is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before start the development. • Developing acceptance tests before starting to implement minimizes delays in development and the chances for miscommunication and misunderstanding. Focus on the conversations about the tests just as much as the actual tests

Compliance

• Considering value prioritization, sometime project work is undertaken to conforming a rule, such as a specification, policy, standard or law (e.g. regulatory compliance)

Customer Value

• Deliver the highest value to the customers as early as possible • The backlog should be customer-valued prioritized while taking into accounts technical feasibilities, risks, dependencies, etc. • Can win customer support

Why do we Estimate?

• Estimating helps in planning • Estimating helps in calculating Return on Investment (ROI) and Internal Rate of Return (IRR), sizing and approving projects • Estimating helps the development team knows its velocity and be able to commit to work accordingly to it • Estimating helps the product owner in decision making, prioritizing and in overall release planning • Estimating helps tracking the progress on a release

Extreme Characters

• Extreme characters help us in visualizing a user who is not at all a normal user. • Extreme characters will helps us identify stories that we would be likely to miss otherwise • Extreme characters may lead to new stories, but may not be necessary to include in the product.

The differences between Kanban and common Agile approaches

• The queues in front of software development teams stay small. • The software development teams focus on completing features as quickly as possible but are not constrained by a time-boxed system. • Kanban is explicit about including the entire value stream, from concept to consumption. Ideas from the customer start the value stream, and the product managers are directly tied to the teams because of the work-in-process limits that Kanban puts on this flow. • No estimation is required in Kanban.

Minimal Marketable Feature (MMF)

• The smallest set of functionality that must be realized in order for the customer to perceive value. • A MMF is a feature that is minimal, because if it was any smaller, it would not be marketable. • A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature

Sprint Retrospective

• The sprint retrospective occurs after the sprint review and prior to the next sprint planning meeting • This is a three-hour time-boxed meeting for one-month sprints. Proportionately less time is allocated for shorter Sprints

Why are Personas important?

• Understand your target audience through understanding their mindset and their environment • Help build features that will be used by the user • Help identify common problems being faced by the user • Understand user driven/external systems • Keep the focus of requirements • Identify user motivations, expectations and goals • Help development teams to focus on their users.

Acceptance Tests

• Used to verify, at the end of iteration, if the feature (user stories) have been implemented like the customer wanted • Are the third C from user stories, "confirmation" • Are defined from example given by the customer • Those examples are applied to the item's acceptance criteria to form acceptance tests

Product Roadmap

•A product roadmap is a high-level plan that describes how the product is likely to grow. •The creation of the roadmap is largely driven by the product owner.

Agile is...

•A set of principles & practices based on the Agile Manifesto •A disciplined project management approach •Business & delivery focused, welcoming change •Agile is a general concept; Scrum and XP are specific implementations of Agile •Incremental framework, frequent delivery & continuous feedback loops •An empirical process - frequent inspect and adapt cycles that minimize waste

Story Map

•A story map is a popular way of depicting a roadmap in Agile projects •A way to effectively plan releases that deliver value to users and the business (When) •Useful model to help understand system functionality through the Users of the system (Who, What, How) •Visual way to identify holes and omissions in the backlog •Allows you to see the big picture (Why) •Provide visibility to the workflow or value chain •Show the relationships of larger stories to their child stories •Help the team confirm the completeness of your backlog •Provide a useful context for prioritization •Plan releases in complete and valuable slices of functionality for maximizing the business value.

(Agile) Incremental Delivery

•Agile team produces deployable software every week •In each iteration, the team analyzes, designs, codes, tests, and deploys a subset of features •The team gets feedback much more frequently •The tight feedback loop also allows Agile teams to improve their plans quickly

Sprint Review

•Held at the end of sprint to inspect the increment and adapt the product backlog if needed •Scrum team and stakeholder collaborate and review what was done in the sprint •Elicit feedback Compare what was committed by the team and what was delivered

MoSCoW

•Must Have - Requirements fundamental to solution - Defines Minimum Usable Subset - basic working solution •Should Have - Requirements important to system - Measured in terms of value or impact •Could Have - Can do without in the short term •Won't have this time - Will wait till later •Why prioritize? - Not enough time to do everything - Not enough resources to do everything - Lack of money or lack of people (or both) •MoSCoW means important things are done first •Musts and Shoulds often deliver 80% of total business benefit •MoSCoW priorities drive sequence of delivery •Target is effort split 60% Must Have, 40% Shoulds and Coulds - Predictable and sustainable delivery

What is your project mission? (steps to define it)

•Select a consumer service and product of interest •Your goal is to identify a digital product to produce •Establish Charter, Product vision, roadmap, release plan •Define operating model, team composition & roles •Determine a Minimal Viable Product •Develop a sprint plan with product increments •Integrate into one consumer mobile based app •Develop a working Prototype of your MVP

Operating Model of an Agile Team

•Team organized around the work •Empowered •Self organize / Self managed •Team pulls the task from queue /backlog •Cross functional •Intensely collaborative

Release Planning

•The purpose of release planning is to commit to a plan for delivering an increment of product value •Release planning is continuously posing a product vision while focusing on those features of greater priority (value) to the business. •Release plans enable delivery in small, end-to-end slices

Iteration Planning

•The purpose of the iteration planning meeting is for the team to commit to the completion of a set of the highest ranked product backlog items. •This commitment defines the iteration backlog and is based on the team's velocity or capacity and the length of the iteration time-box. •Product backlog items too large to be completed in an iteration need to be split into smaller pieces.

Sprint Planning

•The purpose of the sprint planning meeting is for the team to commit to the completion of a set of highest-ranked product backlog items. •These commitments define the sprint backlog •These commitments are commonly referred to as user stories

Agile is not...

•Unplanned •Chaotic •Unpredictable •Open Ended •Undocumented •A methodology •Unconstrained •A "Best" Practice •Without its challenges...