Understanding Agile Development with Scrum

Understanding Agile Development With Scrum

https://www.ifourtechnolab.com/custom-software-development

Topics included • Module 1: Fundamentals of the Agile Development Approach • Agile Manifesto and Agile values, Tackling uncertainty, Customer

responsiveness, Early availability • Module 2: Agile Development Life Cycle • Scrum flow and artifacts, Product backlog, Sprint backlog, Sprints planning, Scrum meetings, Sprint review • Module 3: Roles and Responsibilities • Product Owner, Scrum Master, The Team • Module 4: Agile Requirements Development • Breaking requirements into user stories, Story estimation, Merging and splitting stories http://www.ifourtechnolab.com

Topics included • Module 5: Agile Planning • Release planning, Sprint types, Sprint planning • Module 6: Agile Design • Minimal design, Design for change, Using information hiding to minimize

code changes, Lightweight design documentation • Module 7: Agile Construction • Pair programming, Refactoring, TDD, CI • Module 8: Agile Project Management • Scrum and management, Status reporting, Sprint review agenda, Sprint retrospective agenda, Recovery when things go wrong, Scaling agile projects http://www.ifourtechnolab.com

Module 1: Fundamentals of the Agile Development Approach

http://www.ifourtechnolab.com

Plan Driven Development ď Ź

Development that is characterized by gated stages.

ď Ź

Waterfall - Most common and widely used approach

http://www.ifourtechnolab.com

SDLC - Waterfall

http://www.ifourtechnolab.com

Plan Driven Development – Where to Use? 

Requirements remains same through out the project



Requirements are well understood



Size of the projects are small to mid scale



Highly structured systematic process

http://www.ifourtechnolab.com

Software is dumb- Why?

What the customer really needed

How the customer explained it

How the project leader understood it

How the analyst designed it

What the beta testers received

How the business consultant

How the project was documented

What operations installed

http://www.ifourtechnolab.com

How the programmer wrote it

When it was delivered

Project Requirements • What if • The requirements required to change during the project life cycle?

• Requirements required to meet with business challenges time to time?

• Client wants to out perform the competitors by introducing the product first in the market?

• Businesses and project stakeholders are constantly looking to improve process and innovate. http://www.ifourtechnolab.com

Agile Development Methodology • • • • •

Value driven method Understand and meets the challenges of today’s business Offers much more value to the stakeholders Firm emphasis on customer satisfaction and quick ROI It is all via Iterative approach

http://www.ifourtechnolab.com

Iterative Software Development

http://www.ifourtechnolab.com

What is Agile Development? – Definition • Iterative and Incremental Software development method where requirements and solutions evolve through collaboration between self organizing, crossfunctional teams.

http://www.ifourtechnolab.com

Agile Manifesto • Individuals and interaction over processes and tools Working software over

comprehensive documentation Customer collaboration over contract negotiation responding to change over following a plan.

• While, there is value in the items on the right side, we value the items on the left more.

http://www.ifourtechnolab.com

Principals of Agile Development 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 to the shorter timescale.

4. Business people and developers must work together daily project. http://www.ifourtechnolab.com

throughout the

Principals of Agile Development 5. Build projects around motivated individuals. Give them the environment and 6. support they need, and trust them to get the job done.

7. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

8. Working software is the primary measure of progress.

9. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. http://www.ifourtechnolab.com

Principals of Agile Development 10. Continuous attention to technical excellence and good design enhance agility.

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.

http://www.ifourtechnolab.com

Flavors of Agile Development

http://www.ifourtechnolab.com

Module 2: Agile Development Life Cycle (Scrum) http://www.ifourtechnolab.com

Scrum Process

http://www.ifourtechnolab.com

Scrum Artifacts •

Primary (Main) Artifacts • Product backlog • User Stories • Product backlog sizing • Sprint backlog • Kanban Board (Signboard / Billboard) • Burn-down chart

•

Secondary Artifacts • Acceptance Criteria. http://www.ifourtechnolab.com

Product Backlog •

List that represents customer’s needs and wants

•

Requirements are always defined into user stories in a product backlog

•

Managed by product owner

•

Product owner can add or remove user stories

http://www.ifourtechnolab.com

How To Create Product Backlog?

•

Typical product backlog comprises following different types of items: • Features They are described in the form of user stories • Bugs It is almost same as the feature • Technical Work e.g. Upgrade all developer’s work station to windows 10 • Knowledge Acquisition e.g. Researching about various JavaScript libraries.

http://www.ifourtechnolab.com

Product Backlog- Excel Format

http://www.ifourtechnolab.com

Product Backlog- Excel Format •

Product backlog in this manner is written in the form of user stories

•

The form is like “As a, so that…” e.g. As an administrator should be able to inactive any registered user so that such user can not login to the system

•

The spreadsheet helps to divide each part of the requirements in to specific columns

•

You can add columns as per your requirements like Status column.

http://www.ifourtechnolab.com

User Stories •

User Story is written for the developer

•

Expresses the increment of value to customer

•

Vertical slice through the product.

http://www.ifourtechnolab.com

User Stories Vertical Slice

User Interface

Business Layer

Data Layer

http://www.ifourtechnolab.com

What is Efficient User Stories? •

User Story should fit INVEST acronym Independent

Should be self contained There should not be inherent dependency on another story

Negotiable

Can always be changed and rewritten until they are part of a sprint

Valuable

Must deliver value to the customer

Estimable

Must always be able to estimate the size of a user story

Sized Appropriately

Should not be so big to plan / prioritize

Testable

Must provide necessary information to make test driven development possible

http://www.ifourtechnolab.com

Backlog Sizing •

Estimating anything is a tricky task but comparing anything is simpler and better

•

Sizing a backlog is all about making decision based upon,

•

•

Complexity

•

Amount of work (Efforts estimation)

It is not about how long it will take to do the work.

http://www.ifourtechnolab.com

Sprint Backlog •

Subset of Product Backlog

•

Sprint backlog created during sprint planning meeting

•

User stories and tasks to accomplish or remaining to complete from previous sprint

•

User stories will be divided into tasks during the sprint

•

Task is a small chunk of a user story that can be done by any team member e.g. Database changes required to do for a user story. http://www.ifourtechnolab.com

Sprint Backlog – Excel Format

http://www.ifourtechnolab.com

Kanban Board • • • •

Kanban is a Japanese word of Signboard or Billboard Kanban board is a task board Visible to entire organization Comprises, • All tasks to be done by team during the sprint will be displayed on task board • Setup meetings to gather requirements • Review checks • Research • Testing • Design • Stages of coding. http://www.ifourtechnolab.com

Kanban Board Example

http://www.ifourtechnolab.com

Burn-Down Chart • • • • • •

Visual way to track how the sprint is progressing on daily basis Sprint backlog supplies the information for burn down chart Indicates remaining work Provides early indication if there is a problem in the sprint and the team may not fulfill the commitment Burn down chart is used to analyze during sprint retrospection meeting about how the sprint was progressed and where it can be improved in the next sprint.

There are 2 types of burn down charts, • Sprint Burn Down Chart • Release Burn Down Chart. http://www.ifourtechnolab.com

Burn-Down Chart

http://www.ifourtechnolab.com

Release Burn-Down Chart •

Used to track iteration progress against the release plan in a sprint burn down chart

http://www.ifourtechnolab.com

Alternative Release Burn-Down Chart •

•

What if, •

Requirements are changing frequently in each sprint?

•

New requirements added in the current sprint?

The burn down chart in such cases may not provide the correct result •

e.g. The team was expected to finish 40 story points in a sprint

but

completed only 10 story points.

•

Burn down chart should also provide such impediment ideas so for such cases, use alternative release burn down chart. http://www.ifourtechnolab.com

Alternative Release Burn-Down Chart

http://www.ifourtechnolab.com

Acceptance Criteria – Secondary Artifact •

Set of steps that developer must complete before the story can be considered done

•

Created by product owner with the help of customer

•

Upfront sets the expectation of the user story

•

Helps to write automated tests or to implement TDD

http://www.ifourtechnolab.com

Module 3 Scrum Roles & Responsibilities

http://www.ifourtechnolab.com

Project People Project People

Committed Pigs

Involved Chickens

Lets talk about Pig & Chicken story http://www.ifourtechnolab.com

Pig Roles •

Pigs are people who are committed to the project

•

Pigs handle creating, testing and deploying of the project

•

Typical scrum team size is 5 – 9 people

•

3 pig roles to make a scrum team i.

Scrum Master

ii.

Product Owner

iii. Delivery Team. http://www.ifourtechnolab.com

Chicken Roles •

Are less committed

•

They are the stakeholders and/or interested parties who benefit from the project, but are not responsible for delivering it

•

Chicken roles are, i.

Business Managers

ii.

Customers / Vendors / Sponsors.

http://www.ifourtechnolab.com

Scrum Master - Responsibilities •

Scrum master’s role is much more than a traditional project manager

•

Scrum master liaises with different part of the team from stakeholders to testers

•

Ensures the scrum process is understood and followed by the team

•

Facilitates team meetings & remove any blockages

http://www.ifourtechnolab.com

Scrum Master - Responsibilities •

Ensures no obstacles keeping the team from achieving the goals

•

Isolates the team from outside distractions

•

Working with the product owner to keep product backlog ready for the next sprint.

http://www.ifourtechnolab.com

Scrum Master - Characteristics •

“Servant Leader” – Not the boss of the team but to help the team

•

Helps to align the work in order to deliver value to the customer

•

Point of contact for outside the group

•

Needs to be a top-notch communicator

•

Conflict resolving ability to bring the team back on track

•

Scrum master should be influential

http://www.ifourtechnolab.com

Product Owner •

Customer’s representative to the team

•

Determines customer’s needs

•

Prepares Product Road map

•

Prioritize items so that team always works on items of highest customer value

•

Manages product backlog

•

Responsible for the sign-off of sprint deliverable –Sprint demo

•

Should be motivating the team with clear, elevating goals. http://www.ifourtechnolab.com

Product Owner

http://www.ifourtechnolab.com

Product Owner - Characteristics •

Visionary

•

Decision Maker

•

Collaborator

•

Communicator

•

Analytical – Tracks progress

http://www.ifourtechnolab.com

PO,PM & SM

http://www.ifourtechnolab.com

Product Owner Vs. Scrum Master

http://www.ifourtechnolab.com

Delivery Team •

Group of self-organized people responsible for delivery

•

Team size – 2 to 10

•

Team members – Programmers, testers, front-end designers and other disciplines

•

Team works on each user story to move tasks on next stage in Kanban board

•

No one is a leader, everyone decide as a group what they are going to deliver.

http://www.ifourtechnolab.com

Chicken Roles •

The project is developed for these people

•

Their views are important and must be taken in account

•

Should provide the resources that helps the team to get job done

•

Actively involved during sprint review only

•

Do attend scrum meetings time to time.

http://www.ifourtechnolab.com

Module 4 Scrum Activities

http://www.ifourtechnolab.com

Sprint Planning •

Sprint planning requires before the start of the sprint

•

To determine which features to include in sprint from product backlog

•

Stories are sized with the team via Planning Poker tool

•

Stories are turned into tasks by the team

•

Time estimation elicited for each task

•

Team decides if they can commit to all tasks to complete in a sprint or not.

http://www.ifourtechnolab.com

Daily Stand Ups •

•

Who attends?

•

The Team

•

Scrum Master

•

Product Owner

When?

•

Daily in the same place at the same time

•

No longer than 15 minutes http://www.ifourtechnolab.com

Daily Stand Ups •

What is to discuss?

• To discuss the progress and issues • Each team member answer the following 3 questions, i. What have you done since yesterday? ii. What are you planning to do today? iii. Do you have any problems preventing you from accomplishing your goal? What progress has been made on existing impediments? Can the blockage be removed? or must it be escalated? (The Scrum Master looks after this area.) http://www.ifourtechnolab.com

Sprint Review • • • •

Held at the end of the sprint Team present user stories that are completed Informal demo of the product Who attends?

• The team • Product Owner • Scrum Master • Manager / Customer • The meeting is a direct value addition for the customer by showing the working software • No need for slides and mass of presentation • It gives a chance to customer to see ROI which is not possible in the waterfall model. http://www.ifourtechnolab.com

Sprint Retrospectives •

Held at the end of the sprint along with sprint review

•

Scrum master gives each team mate 3 color post it notes

•

3 colors to represent, •

Things that went well during the sprint

•

Things that were confusing

•

Things that were bad.

http://www.ifourtechnolab.com

Module 5: Agile Planning & Module 6: Agile Design http://www.ifourtechnolab.com

Planning •

Important part of the project

•

Planning comprises, •

Just In Time Planning

•

Detailed Planning

•

User Stories

•

Release Planning

•

Iteration Planning (Sprint Planning) http://www.ifourtechnolab.com

User Stories •

Short description of a feature

•

Represents single unit of business value to the customer

•

It is told from user’s prospective

•

Format As a <type of user>, I want <some action> so that < business benefit> Or, In order for <some reason>, as a <user role> I want <some action>

•

Typically recorded on indexed card during meeting with customer

•

Should always be in a language that customer understands. http://www.ifourtechnolab.com

User Stories •

Must be INVEST (Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable)

•

User story shifts focus from writing about features to discussing them.

•

Details can be added to user stories in 2 general ways, i.

By Splitting a user story into multiple, smaller user stories

ii.

By Adding Conditions of satisfaction.

http://www.ifourtechnolab.com

User Stories •

Who should write user story?

•

Including product owner, every one in the team because involvement of every one makes a big difference to refine each user story and its acceptance criteria

•

When are user stories written?

•

Generally through out the agile project

•

Specifically story-writing workshop should be held near the start of the project / sprint http://www.ifourtechnolab.com

User Stories Acceptance Criteria •

Acceptance criteria should be captured during story generation

•

It can be captured on the reverse side of the user story card

•

It helps to find more details and identifying dependencies

•

Typically each story should have minimum 3 acceptance criteria.

http://www.ifourtechnolab.com

Types Of User Story •

There are mainly 4 types of user stories, •

Baseline User Story

•

Normal User Story

•

Spike User Story

•

Epic User Story

http://www.ifourtechnolab.com

Baseline User Story •

The team should start with a small and easy to size story to begin estimation which becomes a baseline user story.

•

Each user story’s efforts estimate should be relative to this story

•

Baseline story’s estimate must be accurate

•

If baseline story estimate is inaccurate then the whole estimation can be inaccurate.

http://www.ifourtechnolab.com

Spike User Story •

Story is too difficult to estimate due to lack of technical knowledge – Create spike (alternate story)

•

Spike is created for the unfamiliar technology

•

Once spike is completed then development team can estimate the actual user story

•

Spike involves gaining enough technical knowledge to estimate user story e.g. Learning accelerometer, gyroscope readings to develop motion sensing game http://www.ifourtechnolab.com

Epic User Story – Story Division •

Story that needs total more than one week of work is epic story

•

It is usually too big to estimate

•

Divide a story in smaller VERTICAL slices

•

The story should work through all layers of architecture because that provides immediate customer value.

http://www.ifourtechnolab.com

Estimating Stories – Planning Poker •

Planning poker is a group estimation technique

•

Incorporates all team members – software developers, analysts, QA-tester, security and infrastructure experts

•

Each team member brings different technical prospective

•

Customer is also involved only to give answer raised by the team while estimating.

http://www.ifourtechnolab.com

Planning Poker – How To Play?

•

Product owner reads the story

•

The team discusses the feature with the customer to get more details

•

The team is free to ask the questions

•

Scrum maser asks the team to privately give a number to represent the complexity of the story.

http://www.ifourtechnolab.com

Planning Poker – How To Play?

•

To prevent influence, team members should not share their numbers with others

•

Once all has given number then Scrum Master asks everyone to reveal their number

•

If all team member decides the same number then it is assigned to that user story

•

If numbers does not match then the team member with lowest and highest number are asked to explain why they think so. http://www.ifourtechnolab.com

Planning Poker – How To Play?

•

After the discussion, another round of poker is played

•

The process is repeated until the team has unanimously settled on a number

•

In general no more than 3 rounds will be taken

•

If the team is not on conclusion even after 3 rounds then the Scrum Master should take the middle number and move on to the next user story.

http://www.ifourtechnolab.com

Planning Poker – Advantage •

Gives more accurate estimate because we are better in comparison

•

Gives different technical prospective from different team members so all possible loop holes can be identified

•

Helps the team to be on the same page.

http://www.ifourtechnolab.com

Release Planning â&#x20AC;˘

Release is made of enough stories to offer business value

â&#x20AC;˘

Typically it is made of 4 iterations

http://www.ifourtechnolab.com

Iteration Planning •

Iteration planning mainly involves 3 steps, 1. Defining Acceptance Criteria 2. Splitting User Stories in to Tasks 3. Developer “In the Zone”.

http://www.ifourtechnolab.com

Task Board

http://www.ifourtechnolab.com

Module 7: Agile Construction

http://www.ifourtechnolab.com

Agile Construction • •

Agile development should be strategically implemented across the company/development of the project Agile methodology construction blocks involves, • Environment • On site customer • Self Organization • Collective Code Ownership • Shared Understanding • Simple Design • Refactoring • Continuous Integration • Pair Programming • Testing & QA. http://www.ifourtechnolab.com

Simple Design â&#x20AC;˘

Simple design = free of code smells

â&#x20AC;˘

Code smell is any symptom in code indicating potential deeper problem & makes the system more difficult to maintain e.g. Code duplication, Over engineering, Large classes, Dead code, Uncommunicated names.

http://www.ifourtechnolab.com

Refactoring •

Process of improving and simplifying the design of existing code without changing its behavior

•

Allows automated test to be written

•

Makes the application more maintainable

•

Legacy applications often needs to be re-factor in order to strip away dependencies so that automated tests can be performed.

http://www.ifourtechnolab.com

Continuous Integration â&#x20AC;¢

Basic CI Workflow

http://www.ifourtechnolab.com

Pair Programming •

Two heads are better than one – Pair programming

•

Two developers share the duty of completing one user story task

•

Driver & Navigator model

•

Driver – Typing the code

•

Navigator – Reviewing the code, Thinking about next step.

http://www.ifourtechnolab.com

Quality Assurance •

Quality assurance is essential when creating software

•

Having great practices for gathering requirements, working closely with client and understanding all user story without getting the right product is of no use!

•

Agile promotes TDD and UAT.

http://www.ifourtechnolab.com

Quality Assurance • • • • •

“Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle” It’s a practice that adds reliability to the development process.

TDD is a technique where you write your test cases before you write any implementation code.

TDD is a technique for improving the software’s internal quality.

TDD provides , • Good design • A balanced division of functionalities • Smooth evolution • Maintainability • Tests provide a specification of “what” a piece of code actually does http://www.ifourtechnolab.com

Quality Assurance (Cont.)

•

A test is not something you “do”, it is something you “write” and run once, twice, three times, etc.

•

It is a piece of code

•

Testing is therefore “automated”

•

Repeatedly executed, even after small changes

http://www.ifourtechnolab.com

TDD â&#x20AC;&#x201C; Life Cycle Requirements

Requirements

Design Design Testing Implementation

Implementation

Testing

Deployment & Maintenance

http://www.ifourtechnolab.com

Deployment & Maintenance

Conclusion •

Implement agile methodology across the company with Agile Construction Blocks

•

No code will go in production without associated test cases

•

Refactoring helps to improve maintainability

•

CI helps for successful increments

•

TDD helps to improve quality

http://www.ifourtechnolab.com

Module 8: Agile Project Management

http://www.ifourtechnolab.com

Project Management •

Project management is a combination of art and science both

•

You should be well versed with the principals of the project management

•

At the same time you should be practical while taking decision and understanding circumstances

•

Agile project management is more about empowerment

•

Agile projects are not lead by individual like project manager.

http://www.ifourtechnolab.com

Project Management •

Rather projects are lead by the whole team

•

Agile projects works on simple processes that anyone can follow

•

Who manage the agile projects?

•

Project are mainly managed by both Product Owner and Scrum Master together

•

Product owner is responsible for managing business aspects

•

Scrum Master is responsible for implementing agile development processes.

http://www.ifourtechnolab.com

Project Phases â&#x20AC;˘

There are 5 distinct phases for any project,

http://www.ifourtechnolab.com

Agile Project Phases Initiation

>> Product Backlog

Planning

>> Sprint Planning

Executing

>> Sprint

Monitoring & Controlling

>> Manage Sprint

Closing

>> Close Iteration & Release Planning

http://www.ifourtechnolab.com

Planning (Sprint Planning) Inputs 1 Product Backlog (Prioritized) 2 Velocity Achieved Previously

Tools & Techniques Outputs 1 Sprint Planning 1 Sprint Goals Meeting 2 Sprint Backlog 2 Estimating in Points 3 User Stories Selected (Fibonacci)

3 User Stories (Draft)

3 Planning Poker

4

Team Membersâ&#x20AC;&#x2122; Availability

4 Task Breakdown and Estimates 5 Teamâ&#x20AC;&#x2122;s Commitment 6 Cards on Whiteboard

http://www.ifourtechnolab.com

Execute Iteration (Sprint) Inputs

Tools & Techniques

1 Selected User Stories (represented by Cards on Whiteboard)

2 Test Driven Development

2 Task Breakdown

3 Automated Testing

1 Collaboration

4 Continuous Integration or Daily Build 5 Test Early & Often

6 Pair Programming 7 Refactoring

http://www.ifourtechnolab.com

Outputs

1 Working Software for Selected User Stories 2 Test Confirmations 3 Automated Tests 4 Any Related Documentation

Monitor & Control Iteration (Manage Sprint) Inputs 1 Work Completed Yesterday 2 Work Planned Today 3 Impediments Affecting Progress

Tools & Techniques 1 Cards on Whiteboard 2 Daily Scrum/Standup 3 Daily Burn down or Burnup Chart

Outputs 1 Final Burn down or Burnup Chart 2 Velocity Achieved

4 Review Product 4 Working Software for User Frequently / Active User Stories Completed So Far Involvement 5 Address Impediments 6 Definition of Done

http://www.ifourtechnolab.com

Close Iteration (Manage Sprint) Inputs 1 Work Completed Yesterday 2 Work Planned Today 3 Impediments Affecting Progress

Tools & Techniques 1 Cards on Whiteboard 2 Daily Scrum/Standup 3 Daily Burn down or Burnup Chart

4 Review Product 4 Working Software for User Frequently / Active User Stories Completed So Far Involvement 5 Address Impediments 6 Definition of Done

http://www.ifourtechnolab.com

Outputs 1 Final Burn down or Burnup Chart 2 Velocity Achieved

Velocity • • •

Velocity means to find how much work you can commit in a sprint It better helps to estimating the features and providing commitments How to measure velocity – i. Select a sprint as unit to measure velocity ii. Add the estimation of all the tasks of the sprint iii. At the end of the sprint add the hours of the tasks that are completed fully iv. Tasks that are not completed will be considered as zero v. At the end of the sprint the hours you got is your velocity.

http://www.ifourtechnolab.com

Scrum Of Scrum •

Scrum of Scrum is analogues to Daily Stand up meetings (Daily Scrum Meetings)

•

Large Scale projects when there are multiple sprint teams available, each team identifies one person to attend Scrum of Scrum

•

Decision of who to send is belongs to the team

•

Usually the person chosen should be technical – programmer, designer, tester

•

Generally product owner or scrum master does not selected

http://www.ifourtechnolab.com

Scrum Of Scrum Meeting Agenda • •

Scrum of scrum meeting agenda is similar to daily scrum with one more additional question.

The questions to be asked are, i. What has your team done since we last met? ii. What will your team do before we meet again? iii. Is anything slowing your team down or getting in their way? iv. Are you about to put something in another team’s way?

http://www.ifourtechnolab.com

Scrum Of Scrum Example (Large Scale Project) •

Total Resources: 243 People

•

Team size: 9 People in each team

•

Total Sprint Teams: 27 Sprint Teams

•

Scrum of Scrum meetings are held for monitoring and helping cluster of teams

http://www.ifourtechnolab.com

Scrum Of Scrum Example (Large Scale Project)

http://www.ifourtechnolab.com

How agile are you or your team?

•

Questionnaire to ask the team members

•

42 questions present in it

•

Give answer as 1 if you are 100% doing it else 0

•

Take the average of the score of each team member.

http://www.ifourtechnolab.com

42 Points Test 1.

2.

3.

4.

5.

6.

The team is empowered to make decisions.

The team is self-organizing and does not rely on management to set and meet its goals.

The team commits and takes responsibility for delivery and is prepared to help with any task that helps the team to achieve its goal.

The team knows who the product owner is.

Each sprint/iteration has a clear goal.

All team members, including testers, are included in requirements workshops.

http://www.ifourtechnolab.com

42 Points Test 7.

8.

9.

10.

11.

12.

Requirements documentation is barely sufficient and the team collaborates to clarify details as features are ready for development.

Test cases are written up-front with the requirements/user story.

There is a product backlog/feature list prioritized by business value.

The product backlog has estimates created by the team.

The team knows what their velocity is.

Velocity is used to gauge how many user stories should be included in each sprint/iteration.

http://www.ifourtechnolab.com

42 Points Test 13. Sprints/iterations are time boxed to four weeks or less.

14. Sprint budget is calculated to determine how many 15.

16.

17.

18.

product backlog

items/features can be included in the sprint/iteration.

The sprint/iteration ends on the agreed end date.

All tasks on the sprint backlog are broken down to a size that is less than one day.

Requirements are expressed as user stories and written on a card.

The team estimates using points which indicate the relative size of each feature on the product backlog/feature list.

http://www.ifourtechnolab.com

42 Points Test The team generates burn down charts to track progress daily.

Software is tested and working at the end of each sprint/iteration.

The team is not disrupted during the sprint/iteration.

Changes are integrated throughout the sprint/iteration.

Automated unit testing is implemented where appropriate.

There is an automated build and regression test.

Stretch tasks are identified for inclusion in the sprint/iteration if it goes better than expected 26. The Product Owner is actively involved throughout each sprint.

27. All code changes are reversible and it is possible to make a release at any time.

19.

20.

21.

22.

23.

24.

25.

http://www.ifourtechnolab.com

42 Points Test 28. Testing is integrated throughout the life cycle and starts on delivery of the first 29.

30.

31.

32.

33.

feature.

Impediments that hold up progress are raised, recorded on the whiteboard and resolved in a timely fashion.

When someone says â&#x20AC;&#x2DC;doneâ&#x20AC;&#x2122;, they mean DONE! (i.e.shippable).

The team uses the whiteboard to provide clear visibility of progress and issues on a daily basis.

The sprint/iteration goal(s) is clearly visible on the board.

All user stories and tasks are displayed on the whiteboard for the duration of the sprint/iteration. http://www.ifourtechnolab.com

42 Points Test 34. Daily scrums happen at the same time every day â&#x20AC;&#x201C; even if the scrum master isnâ&#x20AC;&#x2122;t 35.

36.

37.

38.

39.

present.

The daily scrum is restricted to answering the standard 3 scrum questions and lasts no more than 15 minutes.

There is a product demonstration/sprint review meeting at the end of each sprint/iteration.

All team members, including testers and Product Owner, are included in the sprint/iteration review.

The sprint/iteration review is attended by executive stakeholders.

There is a sprint retrospective at the end of each sprint/iteration. http://www.ifourtechnolab.com

42 Points Test 40. Key metrics are reviewed and captured during each sprint retrospective.

41. All team members, including testers, are included in the sprint retrospective

meeting.

42. Actions from the sprint retrospective have a positive impact on the next sprint/iteration.

http://www.ifourtechnolab.com

Disadvantage Of Agile 1.

2.

3.

4.

5.

6.

7.

8.

9.

Active user involvement and close collaboration Requirements emerge and evolve Agile requirements are barely sufficient Testing is integrated throughout the life cycle Frequent delivery Sustainable pace System structure tends to degrade as new increments are added Regular changes usually corrupts the structure unless time & money spent on refactoring Has the potential to degenerate into a build & fix model. http://www.ifourtechnolab.com

Module 9: Material & Certification

http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 1

Pro Agile .NET Development With Scrum- Apress http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 2

Scrum Mastery : From Good to Great Servent-Leadership http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 3

Agile Estimating & Planning Your Sprint with Scrum http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 4

Continuous Delivery: Reliable Software Releases through Build, Test, & Deployment Automation http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 5

Agile Retrospectives: Making Good Teams Great http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 6

The Agile Enterprise: Building & Running Agile Organizations http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 7

Agile UX Storytelling: Crafting Stories for Better Software Development http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 8

User Stories Applied: For Agile Software Development http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 9

More Agile Testing: Learning Journeys for the Whole Team (Addison- Wesley Signature Series (Cohn)) http://www.ifourtechnolab.com

Top 10 Books For Agile Transformation 10

Agile Estimating and Planning http://www.ifourtechnolab.com

Certification Bodies •

Popular Main 3 bodies •

Scrum •

•

Scrum Alliance •

•

https://www.scrum.org https://www.scrumalliance.org

Project Management Institute •

https://www.pmi.org http://www.ifourtechnolab.com

Certification Bodies • Other Bodies • Scrum Institute • www.scrum-institute.org • APMG International • www.apmg-international.com • International Consortium for Agile (ICAgile) • www.icagile.com • Scrum Study • www.scrumstudy.com • Agile Certifications • www.Agilecertifications.org http://www.ifourtechnolab.com

Certification Types • PMI ACP (Agile Certified Practitioner) https://www.pmi.org/certifications/types/agile-acp 120 Multiple Choice Questions • Cost: US$ 495 • CSM – Certified Scrum Master https:// www.scrumalliance.org/get-certified/practitioners/csm- certification • Need to take 2 days Scrum Alliance Training Passing Marks: 80% Minimum • Cost: US$ 1000 to US$ 2500 • PSM 1 – Professional Scrum Master, Level 1 https:// www.scrum.org/professional-scrum-certifications • Starts from US$ 150 http://www.ifourtechnolab.com

Thank you!

http://www.ifourtechnolab.com