SCRUM

Ready- ready

The PB is not simply a good list with a certain characteristics. It has to be ready-ready to be used in a sprint cycle. It has to be negotiated between the PO and the team before sprint planning. It has to have value.

Refactoring

improving internal structure only, E.g removing duplicate code.

What is a good size of a sprint task

one person-day or less, so other team members can easily detect when a task is stuck.

Scrum Development Team

1. Cross functional and self Organizing. 2. Attempt to make a "Potentially Shippable Product Increment" Every sprint. 3. Collaborates 4. Have autonomy regarding how to reach commitment. 5. Collocation especially for first few sprints 6. 7+_2 7. Has a leadership role.

3 c's of Scrum

"Card, Conversation, Confirmation"; a "Card" (or often a Post-It note), a physical token giving tangible and durable form to what would otherwise only be an abstraction: a "conversation" taking place at different time and places during a project between the various people concerned by a given feature of a software product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation; the "confirmation", finally, the more formal the better, that the objectives the conversation revolved around have been reached.

Definition of Done

1 approach : Properly tested refactored potentially shippable Detailed Approach: Code Complete Unit tests written and executed Integration tested Performance tested Documented (just enough) Stage a: User story clarity, Task identified, Build setup changes, PO approval, PB updated Stage b: Environment ready, design complete, unit test case written, documentation, pre-release builds. Stage c: Code complete, unit test cases executed, refactoring, code checking, code merging and tagging. Stage D: Automatic code review, peer review, Code coverage, burndown chart ready, release build. Stage e: Functional testing, Regression testing, performance testing, acceptance testing, closure.

PBI (Product Backlog Item)

1) Specifies what more than how? 2) Written in user stories 3) Has a product wise definition of done to prevent technical debt 4) May have item specific acceptance criteria 5) Effort is estimated by the team ideally in relative units. 6) Effort is roughly 2-3 people days or smaller for advanced teams.

Responsibilities of Product owners (Single Ring-able neck)

1. Business Value 2. Prioritize the product backlog 3. Final arbiter of the requirements questions 4. Focused more on what rather than how? 5. Vision and boundaries.

Forecasting

1. Historic Data 2. Specialist team member's capacity

Agile Movement

1. Individuals and interactions over processes and tools. 2. Working Software over comprehensive documentation. 3. Customer Collaboration over contract negotiations. 4. Responding to change over following a plan.

Scrum

1. It is framework for complex work such as new product development 2. It is an iterative and incremental approach which emphasizes on time-boxing. 3. It is a light weighted agile methodology and an alternative to the traditional approaches. 4. Scrum does not encourage "Partially Done".

The Nokia Test

1. Iterations-Time boxes-can a team execute a sprint in 4 weeks or less? Are those sprints stable over and over again? 2. Testing- Getting the software tested at the feature level to make sure that the user can use it and give feedback. That is exhilarates the implementation of the software and doing what the user exactly wants. Gets tests done write away helps reduce the time that goes into it and also the money. 3. Specifications- is there enough information provided by the PO so that the team knows what they need to do? 4.Do they have a PO who can deliver a good PB? 5. Is the PB shown to the team and they estimate it before going into the sprint planning meeting? 6. Is a team using planning poker to estimate the effort required-Planning Poker- teams can estimate 40 times faster than the traditional estimation procedures. It can cut the whole Project costs by 80%. 7. Does the team have a burn-down chart to check if progression in work? If yes then are they updating it? 8. Disruption- Is there anyone pulling people out of the team or causing any mayhem? 9. The team itself- Are they able to operate as a self organizing teams? Finding out about these tests and depending on these test scores the productivity of the team members increases tremendously.

Prioritization Techniques

1. MoSCow-Must have, should have, could have 2. Business Value Based: Requirements with highest business value implemented first (ROI) 3. Kano Model: Customer preference based 4. Value based prioritization: Value, risk, dependency-priority

Scrum Master

1. No management authority. 2. Moves impediments out of the team. 3. Keeps the team away from other distractions. 4. Doesn't have a Project Manager role. 5. Acts as a facilitator. 6. Gets the team out of the way for natural team self organization. 7. Helps people to train on scrum 8. Promotes improved engineering practices. 9. Enforces time boxes, provides visibility. Time Boxing: Having a limit on time availability for meetings etc. 10. Captures imperical data to adjust forecasts. 11. Makes sure scrum artifacts are available. 12. No decision making authority during the sprints. 13. Increase rigor in the definition of done. http://ScrumMasterChecklist.org

Scrum Impediments

1. Organizational impediments 2. Scrum Master Owned Impediments 3. Team Impediments

Effort Estimation Techniques

1. Planning Poker 2. T-shirt Sizes 3. Relative Mass Valuation

Artifacts

1. Product Backlog 2. Product Backlog Item (PBI) 3. Sprint Backlog 4. Sprint Task 5. Sprint Burn down Chart [x: Days spent y: Amt of work] 6. Product/Release Burn down [x: No. of sprints=average velocity] [y: story points]

Roles in Scrum

1. Product owner 2. Scrum Development Team 3. Scrum Master

Retrospective Techniques

1. Safety Check 2. Classic Scrum Retrospective 3. Silent Writing 4. Timeline Retrospective

Ceremonies in Scrum

1. Sprint Planning Meeting 2. Daily Scrum 3. Sprint review Meeting 4. Sprint Retrospective Meeting

Meetings

1. Sprint planning meeting 2. Daily Scrum 3. Sprint Review Meeting 4. Sprint retrospective meeting 5. Backlog refinement meeting.

3 pillars of Scrum

1. Transparency 2. Inspection 3. Adaption

Small Team and Feature teams

4 to 9 members, highly skilled and collaborative with no assigned leadership roles. Scrum highly encourages co-location at least for the first 2 sprints and later after a few months.

Which user story splitting technique to use?

80/20 principle says that most of the of the value to the story comes from one simple functionality. One split reveals the low-value functionality and the other gives out the waste. Go with the split that lets you throw out the waste. Chose that split that gets you more splits. 1 8 points to 2 4's is better than 5 and 3. It helps the PO prioritize accordingly.

Product Backlog

A list of anything we might ever do. A PO prioritizes them high to low. Anyone can add into it. But the PO is responsible for the prioritization. It does not contain task only PBI (Product Backlog items) in user story format or use case scenarios. 1) Everything that the team would do through out the project. 2) Visible to all stakeholders. 3) Any stakeholders can add items. 4) Constantly re-prioritized by PO 5) Items at top are more granular than items at the bottom. 6) Maintained during backlog refinement meeting.

Feature teams

A long lived cross functional cross component team able to operate at all layers of the architecture in order to deliver customer-centric features

Release Candidate

A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs.

Release Planning

A release planning meeting is used to create a release plan, which lays out the overall project goals, objectives and backlog of stories. The release plan is then used to create iteration plans for each sprint. The purpose of the Release planning meeting is to have everyone in the team understand and commit to delivering the agreed release. A release generally fixes only the target date or target scope, but not both since the time and effort to complete all the work is defined only at a high level. The project team and the scrum master are present at a release planning meeting as well as the product owner who determines the priority of items on the release backlog list. High level estimated road map Serves as a base to monitor progress in a project To create a release plan you need: 1) A prioritization ans estimation backlog 2) Velocity of the scrum team (estimated) 3) Conditions to satisfaction (goals for the schedule, scope, resources) Can be feature driven or data driven

Spike

A story or task aimed at answering a question or gathering information, rather than at producing shippable product. 1)Have clear objectives and outcomes for the spike. 2)Be time boxed.

Best practices when Dev Teams relate story points to hours

A story point with less score can take a longer time or sometimes a story point with more score can take lesser time. Hence I would suggest adjusting the scores of the PBIs at the review meetings looking at the burn down charts. However story points are to determine the velocity so that the forecasts for the sprints in the future can be more accurate. Hence not comparing them would be good. https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours http://michaellant.com/2010/07/05/estimating-effort-for-your-agile-stories-2/ Focusing on tasks instead of time can help teams give out quality work.

Walking Skeleton

A vertical slice through all the architectural layers. combination of requirements that will build minimal end-to- end product.

Activities for successful Scrum adoption

AWARENESS that the current process is not delivering accepted results DESIRE to adopt Scrum as a way to address the current problems ABILITY to succeed with Scrum PROMOTION through sharing experience TRANSFER OF IMPLICATIONS of using Scrum throughout the company

SMART

Acronym for creating effective goals S-Specific M-Measurable A- Attainable R-Relevant T-Timely

Burn Down charts (release Planning)

Amount of work remaining against time for the release planning.

Burn Down charts (Sprint)

Amount of work remaining against time for the sprint to end.

Impediment

Anything that can slow down the development process.

Goal of a sprint

Be ready with a potentially ship-able product Increment at the end of each sprint. The Product Owner doesn't need to ship after every sprint but this is the team's job to make it possible.

Why is Fibonacci series used in Scrum effort estimation techniques?

Because it defines a range instead of just a number.

Branching

Branch by features: Branch the Master copy of the code into a branch named for their feature. When they are done developing it they place the developed code back on Master which goes under further testing. The time cycle should be only a couple of days. This works great when the feature are independent. Branch by Sprint: Pull a code copy from Master- where all the user stories are taken into the sprint branch. After completing it, it gets into the test branch and after the release candidate is ready it gets into the production environment. Branching an EPIC: Sometimes a team might not be able deploy everything in one sprint and they might be working on an EPIC and in this case there is one more branch called EPIC which is branched and which acts as a master. The EPIC branch starts along with the Sprint branch and the developers team starts working parallel on both of them. At the end of each sprint the development code has to be integrated into EPICS development code. After the EPIC is over it is merged back into whatever sprint the team is working now. Integration testing is performed and deploying them. Hot fixes to production: Bugs that come up during production have to be dealt with immediately.These can be dealt by one more complexity added to the graph as hotfix_issue pertaining to the issue. we pull it out of testing since it mirrors this branch or pull it out from the production if testing is busy. Once done merge it back into production. This is a very small production cycle. We make sure that the changes are merged into all the other branches too.

Patch

Bug

Build automation

Build automation is the process of automating the creation of a software build and the associated processes including: compiling computer source code into binary code, packaging binary code, and running automated tests.

Requirements Churn

Change in requirements. Waste is what adds no value to the customer.

Sprint Backlog

Committed to do right now. It has an end date. Committed Backlog Items representing the what Sprint Tasks representing the how Scope committed is fixed. Team will discover additional tasks needed to meet the fixed scope commitment during sprint execution Referenced during the daily scrum meeting. Visible to the team. 1) Committed backlog items 2) Tasks not started 3) Tasks in progress 4) Tasks completed.

Continuous Integration

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. Maintain a code repository Automate the build Make the build self-testing Everyone commits to the baseline every day Every commit (to baseline) should be built Keep the build fast Test in a clone of the production environment Make it easy to get the latest deliverables Everyone can see the results of the latest build Automate deployment Tools: Jenkins Buildbot Travis CI

When are regression tests conducted in Scrum?

Continuously as things change; potentially many times a day.

Sashimi

Definition of Done.- Continue incrementing the product till the client says enough.

Difference b/t acceptance criteria and definition of done.

Definition of done implies to all PBIs for a product, while acceptance criteria pertain to one specific item. Acceptance criteria could also form basis of new stories. Jenkins acceptance criteria Scenario: Order a Cheque Book Given the account is in credit And the user has been authenticated And the user's address is available When the user clicks on 'order a cheque book' Then send cheque book to user ...and once you have the happy flow scenario you can then add in all the alternate flows to create a full and useful story that can be used in acceptance testing. Scenario: Order a Cheque Book, no address available Given the account is in credit And the user has been authenticated And the the bank does not have complete user address details When the user clicks on 'order a cheque book' Then ask user for complete their address

Invisible Gun Effect

It's not caused by the boss's actual actions, it's caused by the way subordinate behavior is naturally distorted around bosses. It's normal human nature, not something Scrum Masters can "fix" any more than they can fix gravity.

Technical Debt

Extra development work arises when the code that is easy to implement is used in the short run instead of the best possible solution. (also can be caused due to extra work from bugs and errors in the code).

Rapid Iteration

Flash build...where you go to the customer and build the product with actual customer requirements.

Technical Vs Functional user stories

Functional User Story: The basic user story is structured with functional descriptions of system behaviors. Most often the user drives them. Technical User Stories: Driven to support the upper level behaviour.

Component Team

Grouping people by architectural components.

How does one avoid a QA bottleneck within a sprint? The ratio in our team is 4 developers to 1 tester.

Having a fully trained cross functional team can help. TDD (Test Driven Development) and BDD - Behavior-Driven Development could also help. Its not a QA's responsibility all together to sign off for the Quality in scrum. Hence developers can take care of the bottlenecks too.

Team Size Matters

Hyper productive Teams: 7 members or more Poorer Performing Teams: 15 members

MMP: Minimal Marketable Product

I think many people mean MMP when they say MVP: this is the product with the least amount of features that you consider has market value; you wouldn't want to release your product to the mass market before it has reached this stage.

Organizational impediments

Impediments caused by issues beyond the team's control are considered organizational impediments.

Burn up Charts

It tracks progress towards a projects completion. In the simplest form of burn up chart there are two lines on the chart: A total work line (the project scope line) A work completed line

Epics

Large user stories.

MVP:Minimum Viable Product

MVP is a strategy for iteratively learning about your customers. It "helps entrepreneurs start the process of learning as quickly as possible." In contrast to building a product you think has value, MVP proposes that you learn about your vision by getting potential customers to test an idea/prototype/initial offering, then adapt your product based on the feedback collected. it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort ... Its goal is to test fundamental business hypotheses.

Customize Retrospective Technique

Major Impediments: Distributed locations; Jumping into conclusions;

Value driven approach:

Many customers prefer to see the working software in the early stages to realize what they really need and an iterative process like Scrum is designed to produce the working software very early in the process

Nexus Framework

Nexus is an exoskeleton that rests on top of multiple Scrum Teams when they are combined to create an Integrated Increment. Attention to dependencies and inter operation between Scrum Teams. Roles: Product Owner, a Scrum Master, and Nexus Integration Team Members Artifacts: All Scrum Teams use the same, single Product Backlog. As the Product Backlog items are refined and made ready, indicators of which team will do the work inside a Sprint are made visual. A new artifact, the Nexus Sprint Backlog, exists to assist with transparency during the Sprint. All Scrum Teams maintain their individual Sprint Backlogs. Product backlog-Nexus Sprint Planning- Nexus Sprint Backlog-Scrum Teams-(Nexus Integrated Teams)-Nexus Daily Scrum (Daily Scrums)-Nexus Sprint Review- Nexus Sprint Retrospective-Integrated Increment (PSPI(Integrated)). 3-9 scrum teams. Nexus integration Team: PO, Scrum Master, 1 or more Nexus integration team members. Nexus Events: Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review, Nexus Sprint retrospection, Refinement. Nexus Artifacts: Product backlog, nexus goal, nexus sprint backlog, Integrated Increment Doubt: How are they paid?

How long is a well formed PBI towards the top?

No longer than a quarter of a Sprint.

chirping bird effect.

Not being able perform do perform tasks normally under the presence of others, while you can regularly do them pretty well.

Definition of Done 2

Not only the code complete but the software has to be tested at the feature level. Only then its done-done. That by itself helps the doubling of the productivity. Managing the time to fix a bug can help the team reach done state early. The lesser the time to fix a bug the better their definition of done. In real time they try to get the bug fixes to less than 2 hours. Anytime it goes over that they do a root cause analysis which will generate a list of impediments and by removing them the team can go twice as fast. Definition: Done done means the software is tested at the feature level and there are no outstanding bugs.

Cancelling a Sprint

Only a PO is eligible to do this under the pressure of dev team, stakeholders etc during the sprint. It is done when the goal becomes obsolete. It is very rare since it requires resources to move everything and more meetings.

Product backlog vs sprint backlog

Product backlog- Everything related to the project that we would be ever doing. Sprint backlog- Items on which we would be working only in that particular sprint.

JIRA

Project tracking tool which is widely used in scrum or agile 1) Plan 2) Track 3) Releasing 4) Report Features: 1) Knowledge Management 2) Development workflow 3) Continuous Integration 4) Real-time collaboration

Cadence

Routine development activities The flow or the predictive development rhythm.

Scrum Tools

Scrum wise Target Process Acre note Plan Box Top 3 Jira Version 1 Rally

Metrics

Sprint and Release burn down charts

Capacity Planning

Start the planning session by establishing who has vacation time planned for the upcoming sprint and capturing that information in a vacation story. The vacation story has tasks for each team member's time away, which accounts for some of the team's capacity when stories are being committed. As the sprint progresses and the vacation days are hit, the burndown chart reflects these time-away tasks as being completed along with any other tasks. This prevents the burn-down from falsely indicating a problem. For example, suppose a five-member, well-formed agile team is planning a ten-day sprint. The capacity of the team is quickly established to be 5 members × 10 days × 6 hours per day = 300 hours capacity. The ideal daily burndown is, therefore, thirty hours (300 hours of capacity ÷ 10 day sprint).

TDD- Test Driven Development BDD-Behaviour Driven Development & ATDD-Acceptance TestDriven Development

TDD-Write test, Watch Test Fail, Write Code, Run Tests, Refactor. BDD- Behaviour and Scenarios- Very similar to TDD but instead of Test its replaced by behaviour. Tests that reflect the behaviour desired by the stakeholders. It uses Domain Driven Testing (DDD) to make sure that it more in the english-language type development tests to understand the stakeholder requirements. Ex: Cucumber GWT-Given, When and Then ATDD- Discuss, Distill, Develop, Demo. ATDD focuses on external quality of the software. Ex: FitNess

Information Radiators

Task Boards or Sprint Burndown charts.

Sprint planning Meeting

The PO and the Scrum Dev team will agree to the Sprint goals and negotiate which items from the product backlog will be committed to the sprint backlog. 4 hours time box to plan a 2 weeks sprint. 8 hours time box to plan a 4 weeks sprint List of tasks necessary to complete the committed PBIs. Committed PBIs---Split into tasks----Tasks assigned to individuals-sprint goal Scrum Master- Check if eveyone is committed to the PBIs even if it requires different tasks. Scrum Master commits to keep the team away from other work. PO will guarantee availability during during the sprint to finalize on requirements questions. And would volunteer to be available during the Daily Scrum. Sprint commitment is now called Sprint Forecast according to the scrum guide. Prioritizing techniques: All these techniques are used because they focus more on quality than quantity. 1. MoSCoW(Must, Should, Could or Won't) It works with story cards. 2. Kano model: Customer Satisfaction with the level of functionality that is being provided. Value, Quality and Innovation. a) Satisfaction b) Execution Three types of requirements: a) Performance requirements b) Basic Requirements c) Excitement Requirements Excitement today=expected tomorrow=will be asked for later d) Reverse Requirements: Increase satisfaction when they are missing. e) Indifferent- Doesn't make a difference to people. 3. Value Stream Mapping- Uses flow charts to illustrate the flow of information needed to complete the process. This process can help find non value added elements. 4. QFD (Quality Function Deployment)

Story Point

The points assigned to a user story by the team depending on the difficulty of the story.

Sprint 0

The sprint that has to be implemented before starting the actual scrum project. No PSPI Eg: Assembling the team Assigning the s/w and h/w etc Basic skeleton of the project.

WIP

Work In Progress: Better Measure of work- How much work has been finished.

Capacity

The total capacity of the team should be based on the following equation: # of team members × # of days in the iteration × (no more than) six hours.

Themes

Themes can contain one or more epics. Multiple themes can be associated with a product, but a theme cannot be associated with more than one product at a time.

Force Ranked

There is only one thing at the top of the prioritized product backlogs. Getting an organization to do that is considered a break through.

What happens to unfinished tasks within a sprint?

They are marked as "Not Done". There is no in between in Scrum. The PO gets these user stories as high as possible during prioritization after they are added into the product backlog. This is not always the case, but this would help the team add the task into their next sprint and finish the work. However the velocity chart is built without the partially finished task, the reason is the velocity chart has to be kept transparent.

Feedback Loops

They encourage us to inspect the product that we are building and the processes we are following.

Backlog Refinement Meeting/ Product Backlog Grooming/ Backlog Estimation/ Story Time

Time Box: Same duration each sprint(5% of every sprint activity) 4 hours Some days before the Sprint Review Meeting to give the PO a little time to prioratize the user stories. PBI (Product Backlog Item)- INVEST-Independent, Negotiable, Valuable, Estimable, Small and Testable Purpose of Meeting: a) Estimation of effort Effort Estimation Techniques: 1.Planning Poker 2.T-shirt sizes 3.Relative Mass Valuation b) Clarification of requirements Decomposition of large PBIs into small user stories. Strategies to split a PBI into smaller user stories: 2 types- horizontal and vertical splitting. Horizontal Splitting- Goes with applications layer or the kind of work. This again becomes like the water fall model and hence not encouraged. Vertical splitting- 1) Split by workflows 2) Split by business rules 3) Split by happy/unhappy flow 4) Split by input options / platform 5) Split by datatypes or parameters 6) Split by operations 7) Split by test scenarios / test case 8) Split by roles

Daily Scrum Meeting

Time Boxed to 15 min What did I do Yesterday? What will I do today? What impedes me? Sprint Task Boards: Not Started, In progress, Completed. Sprint Burn Down charts, Impediments List. Side Bar Topics (Scrum after Scrum): Ex: The Product owner was not available.

Sprint Review Meeting

Time Boxed to 3 hours. 1) Open to stakeholders. Time Boxed according to the sprint length-4 hours 2)Live Product demonstration. (PSPI) 3)Product owner will decided if the acceptance criteria for the accepted PBIs have been met as in the Sprint planning meeting and if the goals have been met. 4) Items which are not done will be moved back to the Product backlog. 5) Lastly we will listen to the stakeholders product feedback which may result to new requirements for the PO to prioritize them according to his vision. Provides feedback about the product and its emerging requirements. Scrum Master should help the Po and the stakeholders to convert the feedback to new product backlog items for prioritization by the PO.

Sprint Retrospective Meeting

Time Boxed: 3-4 hours for a 1 month sprint. The purpose of the Sprint Retrospective is to: 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. Impediments: Invisible gun effect, human tendency to jump to conclusions, dispersed teams. Used Mostly for learning what went well in the sprint. Provides feedback about the processes used by the team to build the product. Scrum Master: Facilitates the meetings and does not involve with the content of the meeting. They try to create a learning environment. They list out the happenings. Status leveling techniques: a)Safety Check: 1) Give out blank ballots 2) Think of a situation in your life which you left unsafe, uncomfortable or awkward. 3) Now bring yourself to the mos comfortable and relaxed situation ever. 4) Now ask them to jot down the level of safety, description and comment on them. 5) Now collect them and tally their votes. 6) Ask them to interpret the histograms of the results. This activity can help understand the team's psychological comforts and feelings. especially during the initial sprint. b)Focused Conversation Principles: Objective Question (What Happened?) Reflective Questions (How do we feel about it?) Interpretive Questions? (What does it mean?) Decision Questions(What are we going to do about it?) c)Basic retrospective d) Silent writing: Silent Writing is a technique implemented to hear out all the team members problems and then make decisions. Objectives: categorize them into Good, bad, neutral, things you weren't sure you wanted to write. e) Timeline retrospective: Write down your recollection of previous sprint events. Stick them on the timeline to check when they happened.(Beginning or towards the ending) Have a discussion later. The timelines are usually defined for the scope of the sprint. But they can also be for the release or the team history. Classic Scrum Retrospective: What went well? What could have been done better? Decisions: In the initial sprints the scrum master looks for closures. But in the later stages the team relies less on them and the ScrumMaster can focus more on organizational impediments. Then the team has to be asked to write down the decisions. Goal: The major goal of a retrospective meeting is to be able to come up or understand that one impediment which is a bottle neck and that has to be removed to speed up the process.

As sprints move on what would be the best approach?

To assign stories to one or multiple team members instead of assigning them task.

Focus Factor

Used to measure the change in velocity with the change in capacity. F=Optimal velocity/capacity Velocity: The number of story points in a given sprint Forecast: Focus Factor x capacity Capacity:Capacity: The number of working hours of the team members It is used to forecast on how many sprint commitment the team would should make in the future.

Hybrid Models (Water-Scrum-Fall)

Usually in the plan-Build-Test- Deploy, Scrum comes into play at the build phase where agile teams start working and later again it gets into the traditional waterfall approach and plans for a release. At the build phase this is how it is implemented: Analysis Development Test and showcase

GIT(Getting Started) Version Control

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Example:If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem

Velocity

When the PO considers the items done they will be counted as the velocity. Its purpose is to help the PO forecast. Calculated in story Points(Number of story points per iteration). This can be optional. Initial velocity- Estimated velocity before no data is present. text book definition: 1/3rd of capacity. But usually at the start of the sprint an arbitrary value is considered and the processes goes ahead from there. Average velocity- sum of story points from all sprints/number of sprints Optimal Velocity- The point where it has reached the highest.

When do we use Scrum?

When the requirements are uncertain and technology is unknown. In other words when the work is more unpredictable.

Blocker

When there is an obstacle and the entire process has to be altered.

Test Driven Development

Write Tests (initially would be failing tests) Write product code Refactor Code Finally getting the normal use case done.

How to calculate technical debt ?

You cannot

INVEST criteria

characteristics of a good story? I-independent N-Negotiable V-Valuable E-Estimable S-Small T-Testable

Software release life cycle

pre-alpha- unit testing Alpha-White-box techniques- feature complete Beta-usability testing Open and closed beta: Open Beta: Open betas serve the dual purpose of demonstrating a product to potential consumers, and testing among an extremely wide user base likely to bring to light obscure errors that a much smaller testing team might not find. Closed Beta: closed beta versions are released to a restricted group of individuals for a user test by invitation, while open beta testers are from a larger group, or anyone interested. Private beta could be suitable for the software that is capable to deliver value, but is not ready to be used by everyone either due to scaling issues, lack of documentation or still missing vital features. Release Candidate: A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs. A release is called code complete when the development team agrees that no entirely new source code will be added to this release. Release phase: Release to Manufacturing (RTM): the software is sold as part of a bundle in a related computer hardware sale and typically where the software and related hardware is ultimately to be available and sold on mass/public basis at retail stores to indicate that the software has met a defined quality level and is ready for mass retail distribution. General availability (GA): Gone Live Release to web (RTW): Release to web (RTW) or web release is a means of software delivery that utilizes the Internet for distribution. No physical media are produced in this type of release mechanism by the manufacturer. Support: During its supported lifetime, software is sometimes subjected to service releases, patches or service packs, sometimes also called "interim releases". End-of-life: When software is no longer sold or supported, the product is said to have reached end-of-life, to be discontinued, retired, or obsolete, but user loyalty may continue its existence for some time, even long after its platform is obsolete

Junk Stories

user stories that have no value. More than 1/3rd of what they build is junk sometimes and this they come to know only later with customer collaboration. 65% of features that are build are never used by customers. It needs to be estimable. Testable-acceptance test. Size of the story. INVEST criteria has to be met to tag the backlog as ready ready.

Study board

visual representation of software product progress 1) To Do 2) In-progress 3) Test 4) Done Use color codes to track the progress of each task.