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