Scrum

scrum of scrums (SoS)

- important technique in scaling Scrum to large project teams. - allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration. - Imagine a perfectly balanced project comprising seven teams each with seven team members. Each of the seven teams would conduct (simultaneously or sequentially) its own daily scrum meeting. Each team would then designate one person to also attend a scrum of scrums meeting. The decision of who to send should belong to the team. Usually the person chosen should be a technical contributor on the team—a programmer, tester, database administrator, designer, and so on—rather than a product owner or ScrumMaster. - The attendees should change over the course of a typical project. The team should choose its representative based on who will be in the best position to understand and comment on the issues most likely to arise at that time during a project. - For instance, early in a project the issues brought up at the scrum of scrums meeting may center mostly on technical issues or user experience design. Teams may opt to send someone strong in one of those areas to those early meetings. - Later, issues may center around how to collaborate on testing, and so testers will be the more likely participants. - If the number of teams participating is small, it may be acceptable for each team to send two representatives—a technical contributor, as described above, and a ScrumMaster—if the teams desire.

Vertical slicing

-Agile is very big on the concept of one team. There is no UI, SOA, or data team. There is only one team, focused on delivering a suite of features for the customer. -can be prioritized -no overhead to coordinate activities across multiple teams can be done in 10 ways 1. workflow steps 2. business rules 3. happy/unhappy flow 4. input option/platform 5. data types or parameters 6. operations 7. test scenario/test case 8. roles 9. optimize now vs optimize later 10. browser compatibility

Scrum master

1. no management authority, no project manager role(project management is done by team and PO) 2. Facilitates the Scrum process 3. protects the team from distractions & interruptions, Helps resolve impediments 4. teaches the team how to use scrum 5. Promotes improved engineering practices 6. provides visibility 7. enforces time boxes 8. Creates an environment conducive to team self-organization 9. Captures empirical data to adjust forecasts 10. Has a leadership role

burn up chart

-burn down chart shows work remaining -should be used when work is constant -burn up chart shows work completed -when work is changing -this chart shows all the work(prev+added) -so if SM looks only at the burn down chart he myt think no progress bt looking at burn up he ll knw work is being added so he ll adjust that

scrum task board

-make the sprint backlog visible by putting it on a Scrum task board. -Team members update the task board continuously throughout the sprint; -if someone thinks of a new task, she writes a new card and puts it on the wall. -Either during or before the daily scrum, estimates are changed (up or down), and cards are moved around the board. burn down chart is also shown on it sometimes story to do work in progress to verify done

Horizontal slicing

-projects are broken up roughly along architectural lines. -That is there would be one team for UI, one team for business logic and services (SOA), and another team for data. -adv- good communication and consistency within each slice -disadv-Only when all the layers are hooked up do they offer any value. -individual items do not offer business value -increase bottlenecks, instead of reducing them -cant be prioritized..evrythn is imp -That's why agile is so big on slicing projects vertically.

2 types of roles

1. Chicken 2. Pig

Sprint backlog

1. Contains committed PBIs negotiated between the team and the PO 2. has an end date 3. has committed backlog items representing the what and sprint tasks are identified(not started, in progress, completed) representing the how - Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution - Visible to the team - Referenced during the Daily Scrum Meeting

feature driven development(FDD)

1. Develop overall model 2. Build a features list 3. Plan by features 4. Design by features 5. Build by features

estimation techniques

1. Planning Poker 2. T shirt sizes 3. Relative Mass Valuation 4. Bucket System 5. Dot Voting 5. Numeric Sizing (1 through 10) 6. Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) 7. Dog Breeds (Chihuahua,.........,Great Dane)

Extreme Programming

1. shorter iterations of 1-2 weeks rather than 2-4 2. team can change features as long as they havent started working on that features, unlike sprint 3. customer decides the the order and team executes it in same manner, unlike PO doing prioritization and team executing it in wtev order they want in sprint 4. emphasizes more on engineering practices like TDD, pair programming unlike scrum where teams are self organizing and cross functional to decide wtev fits them - it has freq releases in short development cycles - intended to improve productivity and introduce checkpoints where new cust requirements can be adopted feature: pair programming extensive code review unit testing integration testing user stories spike solutions simplicity and clarity in code expect changes in req freq commn with customers disadv good only for small to med projs code centric-more focus on code than desgin..s/w dev requires gud design no focus on quality

Sprint 0

1. team needs to be assembled 2. hiring or moving people onto the project 3. hardware to acquire or at least set up 4. write an initial product backlog (just at a high level) 5. Minimum viable product is created

potentially shippable product

A potentially shippable product is one that has been 1. designed, 2. developed and 3. tested and is therefore ready for distribution to anyone in the company for review or even to any external stakeholder. Adhering to 1. list of "done" and 2. acceptance criteria ensures that the sprint product is truly shippable.

ATDD

high level business perspective With acceptance test driven development the focus is verifying work is done by passing acceptance tests. As it is dealing with acceptance tests it will usually be at the functional test level. ATDD is close in concept to BDD, but with a stronger focus on the testing aspect as validation ATDD tools would include Cucumber and Fitnesse.

task

A task is a specific "todo" with a given work estimation. A Feature can be broken into multiple tasks and so does a User Story. A task will be something like "Add new column to database called Rate and model it in the application - 1 hour of effort", or "create javascript function to validate input on price field - 1.5 hours of effort" or "create landing page for our campaign with Nike and connect it to our analytics system - 3 hours". Task resolution will always be much smaller and much more technical than Feature or User Story. It will explain what to do rather than why.

definition of done

A very simple definition of done can be encapsulated as: 1. Code Complete 2. Test Complete(unit, integration, performance, regression) 3. refactored properly 4. Documented (just enough) 5. Approved by Product Owner

Sprint Retrospective Meeting

All the meetings are regarding product but this one is regarding the assessment of the process. Its mostly about learning from previous sprints for process improvement by asking 2 questions 1. what went well during sprint 2. what could be improved in next sprint Techniques 1. Safety check 2. classic scrum retrospective 3. focused conversation principles (Objective, reflective, interpretive, and decisional (ORID)) 4. silent writing 5. timeline retrospective 6. decisions Impediments -presence of people who conduct performance appraisals -invisible gun effect -human tendency to jump to conclusions and propose actions too quickly -geographic distribution

Pig

Actual doers, committed to projects, creates tangile deliverable eg scrum master, PO, developers, testers

impediments and blockers

As soon as the first Sprint has started, each Team Member can add the so-called impediments (Blockers) to a list. Each Team Member announces their Blocker for the implementation of a task as soon as it arises and places it in the list of Blockers. It is the task of the Scrum Master to eliminate these Blockers. An impediment is anything that slows down or diminishes the pace of the Team. When the Team is confronted with impediments (or obstacles), the Team could move forward but in advancing they may generate waste. Or the whole process of making progress is more difficult than it should be (think about the little girl in the picture). In contrast, a blocker is anything that stops the delivery of the product. Without the elimination of the blocker, the Team cannot advance at all. We can think of them as internal and external impediments.. on internal impediments we still have control since things gtin delayed cz team's internal reasons and we can do something about it but if the impediments are external (blockers), things arent our control anymore. so it becomes a kind of blocker..without it team cant even move forward..

Program Level

At the Program level, SAFe focuses on the principle of alignment as the efforts of a number of agile teams are integrated to create customer value. VersionOne helps you plan and track your program increments, and coordinate all of the activities of your release trains.

role of BA

Business analysis is a key part of this product owner team and also, as you rightly mention, within the development team. 1. During a Sprint, BAs work on analyzing requirements for the Sprint(s) to follow. They do however actively support the Scrum team in case of (business related) questions/misunderstandings, etc. in the current Sprint. 2. Thus, BAs are not part of the core Scrum team, but rather part of the project team as a whole. This is because they are not working on the same context/goal within a Sprint. They are doing analysis for future Sprint(s), while the Scrum team works on items that have already been analyzed earlier (if not fully, at least at a great extent). 3. BAs work in analyzing requirements for future Sprint(s) is facilitated by the so called "backlog grooming cycles" that take place in parallel to the "Sprint cycles". BA to PO 1. Help the sponsor and product owner define and articulate the business problem and product vision 2. Elicit requirements using a variety of techniques, including facilitating cross-functional requirements workshops 3. Assist the product owner in developing user stories and the associated acceptance criteria so the delivery team will know when they're done. These criteria need to be more complete than, for example, "the order has been placed." I have found that creating specific criterion tends to be difficult for product owners. Trace user stories to business objectives and the product vision and throughout the sprint to ensure it's actually been delivered as imagined. Model the "as-is" and "to-be" business processes. Model the expected system interactions, particularly when software is being developed. Look for gaps in data requirements between what is in place and what is needed. Model the data requirements or work with the appropriate people to ensure that the data will support the new solution. Create mock-ups of the new user interfaces. Support the product owner by discussing business and technical impacts of and dependencies related to priority decisions. Assess how ready the organization is to accept the change.

3 C's of agile

Card - write a story card Conversation - collaboration meetings to get more understanding of the cards Conformation - wrting dod and acc criteria

Kanban

More focus is on quality rather than quantity. Scrum, which focuses on constant communication between team members via frequent short ceremonies. I've often seen Scrum used as the framework for an agile process, with a Kanban board used as the primary tool to communicate progress to people outside the team. Kanban, which focuses around the Kanban board (at least in my experience). The board holds the tasks agreed on for an iteration, and team members choose tasks move them to the different state columns as they work. There are other agile methodologies, but the Scrum/Kanban combination is one of the more common varieties.

self organizing and cross functional

Development team are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality cross-functional means that the team has all the skills necessary to turn Product Backlog Items into a done Increment. It does not mean that each member has all these skills. So your description seems to meet that minimal requirement.(jack of all, master of some) The idea of Scrum is not to force someone into coding who has been testing all his life It is rather to encourage teams to overcome silos of traditional disciplines, learn more and be more robust against unexpected changes (like a tester getting sick). In the example of "developers" and "QAs" you might notice that the time between a bug emerging and a bug fixed will be reduced drastically.

FDD Vs Scrum

FDD and Scrum Similarities Collaborative. Improved communication Completely developed and tested features in short iterations Progress can be tracked at different granularities Emphasis producing quality components FDD and Scrum Differences Scrum: Does not specify any particular engineering practice although parts of XP are frequently adopted. Focus on producing vertical slices of functionality acceptable to product owner. Shorter feedback loops Self-organizing teams Shared code ownership FDD: -Specific engineering practices i.e. design/code inspections, tests -Domain driven -Longer feedback loop -Feature team have recognized roles i.e. Project Manager, Chief Architect, Development Manager, Chief Programmer, Class Owner, and Domain Expert -Class ownership

Scrum Planning Meeting

Facilitator - SM Members- Team, PO, SM Time - 4 hrs Purpose- Basically 2 parts 1. for committing to PBIs 2. to come up with tasks these 2 parts are combined when only 1 team and PO available for whole meeting 1. they ll agree to sprint goals 2. negotiate which PBIs will be committed to Sprint backlog 3. come up with the tasks (40% tasks identified here, 60% identified during execution phase) which are necessary to complete the committed PBIs (wont be able to identify all of them) "who will do what" is not decided here, bt during execution. if now they commit and then dont do it, problem Result - Sprint Backlog

Chicken

Just boss around, dont do any work, just give directions, advise they are the people for whom product is being developed eg functional manager, stakeholders

Work Forecasting

Mathematical technique by calculating focus factor. Focus Factor = Optimal Velocity / Capacity Forecast = Focus factor * available capacity for iteration

Sprint Review Meeting

Members- Team, PO, SM, stakeholders also allowed purpose- 1. live demo of potentially shippable product increment given, no reports 2. PO declares if PBIs meet acceptance criteria or not 3. PO declare if sprint goals met or not 4. stakeholders feedback is taken. -after which new PBIs are discovered and existing ones re prioritized by PO -considered done only if PBI meets acceptance criteria and definition of done, -not done or partially done are moved back to Product backlog so that they can be done in future sprints -even if a PBI is done and not tested its declared not done cz its not shippable when PO declares PIBs as done they are used to measure *velocity* with help of assigned story points(efforts) to those PBIs (useful for PO to forecast) Iterative development, a value-driven approach, allows the creation of products that couldn't have been specified up front in a plan-driven approach. after review PB gets bigger n bigger after sprints so to meet deadlines of release date its imp to constantly re prioritize the PBIs n get high prior on top

why Fibonacci series

One main reason is to not have debates/estimates like: 19,20, 21, 23 Story Points. In agile estimation is usually about comparing relative size, it's clear that 1 Story Point is significantly smaller than 10 Story Points, but 10 SP vs 9 SP is not much different. You want to make sure that bigger numbers are rough estimates and you're not sending to your stakeholders message that you know exactly how big item is. BTW: That's the reason you have 20 instead of 21 which is valid Fibonnaci sequence number. The Fibonacci series also better represents the fact that uncertainty grows proportionally with the size of the story. The differences between 1, 2 and 3 point stories are probably better understood than the differences between a 20 and a 40. This is reflected in the distance between story sizes.

agile methodology

P.S. => these notes were written by me and after discussing all these things with my mentor she asked me to make changes which i have in my mind but never got time to make those changes here so plz reconfirm things before presenting to your mentors. group of methodologies based on certain principles..iterative development

Team Level

Teams are what power the agile release trains. Whether your teams are practicing ScrumXP or Kanban, VersionOne provides a centralized system for coordinating multiple teams, while giving each individual team a dedicated, streamlined environment to collaborate and deliver working software with ease.

Value Stream Level

Teams are what power the agile release trains. Whether your teams are practicing ScrumXP or Kanban, VersionOne provides a centralized system for coordinating multiple teams, while giving each individual team a dedicated, streamlined environment to collaborate and deliver working software with ease.

Stretch goal

Some teams prefer to leave plenty of excess capacity in each sprint, perhaps so there is time for emergent needs or experimentation. Other teams prefer to fill the sprint to the best of their ability to forecast their capacity. Still other teams like to take on a "stretch goal" each sprint, which is kind of a product backlog item that is not quite in the sprint, but is one the team hopes to complete if the sprint goes well.

Daily Scrum and Sprint Executioin

Stand up meeting every morning @ 10 AM @same place Duration = 15 mins Memebers: SM, Team, PO(optional) purpose- 1. 3 questions everybody adressess, what i did, what ill do, what problems i faced 2. also a sidebar list is prepared(for irrelevant topics which can be discussed after the meeting) 3. everyone should be present. imp. Execution - TDD(Test driven development, test, code, refactor) - continuous integration server running regression testing - pair programming done Artifacts- information radiators - current Sprint Task List, - Sprint Burndown Chart, - Impediments List. -if boss present, invisible gun effect -a team that needs additional expertise in product requirements will benefit from increased Product Owner involvement, completion- when timebox expires output - potentially shippable product increment

invisible gun effect

THE INVISIBLE GUN EFFECT HAPPENS EVEN WITH THE NICEST BOSS IN THE WORLD. 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. It's most visible to the lower-status people (which might include newhires, people with less impressive job titles, etc.), less visible to higher-status people (perhaps including senior developers, socially confident people, people with better technical skills than social perception skills, and Scrum consultants), and practically invisible to bosses who haven't done an A/B test yet.

chirping bird effect

That's often a good time for the trainer to leave the room! We can talk about self organization until we're blue in the face, and they won't really get it until we leave them alone — temporarily — to let them do it. I heard a story of one Scrum coach taking a nap under the table to get a team to step up more, and of Ken Schwaber standing outside the door of the team room during a Daily Scrum. I've seen teams have breakthroughs in self management when the person traditionally responsible for managing them left the room. I am inspired by the breakthroughs Scrum led to, especially among the lower status team members who aren't well represented in this discussion.

Portfolio Level

The Portfolio level is where the strategies that drive your enterprise initiatives are determined and where value stream funding and epic-level decision making occurs.

Agile pi

The Program Increment (PI) is the largest plan-do-check-adjust (PDCA) learning cycle in SAFe. A PI is to the Agile Release Train (or Value Stream) as an Iteration is to the Agile

Cadence

The purpose of a cadence is to establish a reliable and dependable capability which demonstrates a predictable capacity. Cadence gives some confidence in the upcoming work when we are triggering rather than scheduling work. Thus cadence is what gives a team a feeling of demarcation, progression, resolution or flow. A pattern which allows the team to know what they are doing and when it will be done. For very small, or mature teams, this cadence could by complex, arrhythmic or syncopated. However, it is enough to allow a team to make reliable commitments because recognizing their cadence allows them to understand their capability or capacity.

user story

User Story is a single "user flow" from a Feature I described above. "User can enter his password and re-enter it for password verification. If the passwords are not matched, the system will show a message". Another example: "User can enter his password; the system will check the password's strength by [rules] and notify the user if the password is not strong enough". By itself, from User Story is hard to understand the entire picture, but it's a smaller unit of work to plan and execute by.

stages of group development

forming, storming, norming, performing

difference between epic and theme

While the stories that comprise an epic may be completed independently, their business value isn't realized until the entire epic is complete. This means that it rarely makes sense to deliver an epic until all of the underlying stories are complete. In contrast, while stories comprising a theme are related, each is independent enough to be delivered separately and still provide some measurable sense of business value.

Sprint

a time period of 7-30 days, usually 15 days in which development occurs on a set of backlog items that has committed to

Velocity Driven sprint planning

based on the premise that the amount of work a team will do in the coming sprint is roughly equal to what they've done in prior sprints. The steps in velocity-driven sprint planning are as follows: 1. Determine the team's historical average velocity. 2. Select a number of product backlog items equal to that velocity. ----3. Identify the tasks involved in the selected user stories and see if it feels like the right amount of work. --------4. Estimate the tasks and see if the sum of the work is in line with past sprints.

Commitment driven sprint planning

brings the top-priority product backlog items into the meeting and describes them to the team, usually starting with an overview of the set of high-priority items.

acceptance criteria

its different for each item whereas def of done is same for all items in backlog both are musts these requirements have to be met for a story to be declared as complete at review meeting

Spiral model

incremental model with emphasis on risk analysis (both technical and managerial risks) 4 phases 1. Determine objectives Kind of requirement gathering is done 2. Identify and resolve risks risks and alternative solutions are identified prototype is produced after this 3. Development and test Detailed design code integration test deploy 4. Plan next iteration adv 1. risk reduction 2. new features can be added 3. software produced early disadv 1. specific expertise needed 2. highly dependent on risk analysis 3. complex than waterfall and hence costly

capacity

no of people * no of hrs * no of days but thats too much to estimate.. better to use focus factor for estimating

Velocity

rate at which a team delivers stories from the product back log used to measure future commitments(forecasting) OR work(story points) done by the team in one sprint or iteration from prev sprint ull have focus factor=vel/cap(cz u hv predicted vel here) after few sprints ull have actual focus factor n ull be able to forecast the velocity for coming sprints velocity = focus factor * capacity

focus factor/capacity planning

used to measure the change in velocity in the instance of a capacity change it will vary from person to person Focus factor is teams ability to remain focussed on the sprint goals without any other distractions usually ranges from 0.6 to 0.8 real capacity = total capacity * focus factor (real commitments can be made against this real capacity) focus factor(F) = velocity(V) / capacity(C) 1. commitment driven(feature driven) 2. date driven

work in progress(WIP)

- Teams should limit user stories accepted into a sprint based on their sustainable velocity. - limits also highlight bottlenecks in a team's delivery pipeline before a situation becomes dire. So in Scrum WIP is limited per unit of time. In Kanban WIP is limited per workflow state.

Rational unified process(RUP)

- 94% of fortune 500 companies use this because they dont know what they want but they are very sure about what they dont want - disciplined approach to assign roles and responsibilities - focused on developing high quality software that meets the needs of its users within a predictable schedule and budget - can be tailored to specific organization or project needs 4 phases 1. Inception scope defined is the project technically and commercial feasible or not 2. elaborate elaborate software architecture have proof of concept prototypes done solutions and components we are going to produce are actually going to work 2gdr 3. construction build, test, verify, validate the software by starting with most abstract version and adding components or capabilities one by one doing iterative and incremental development and test it so that we have something that functions correctly 4. transition we have the product be used by few customers initially and then more no of customers license fee is huge for rational s/w so very costly its usually customized to make ti cheaper

release planning meeting

- High level planning for scrum - decide the milestones - number of sprints required based on the capacity of the team 1. used to create a release plan, which lays out the overall project goals, objectives and backlog of stories. 2. it is then used to create iteration plans for each sprint. 3. purpose - to have everyone in the team understand and commit to delivering the agreed release. 4. 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

MVP(minimum viable product)

- a developoment technique to develop product with the smallest possible feature set that addresses the user needs, creates the desired user experience - An MVP has three key characteristics: It has enough value that people are willing to use it or buy it initially It demonstrates enough future benefit to retain early adopters It provides a feedback loop to guide future development strategy for avoiding the development of products that customers do not want. The idea is to rapidly build a minimum set of features that is enough to deploy the product and test key assumptions about customers' interactions with the product.

SWAG(Scientific wild ass guess)

- a rough estimate made by an expert in the field, based on experience and intuition - In the Agile world, Swag is to portfolio items what story points are to backlog items. Swag provides a way to compare the size, time, and effort that it will take to complete a set of features without going through detailed backlog estimating activities. - A unit such as Team Weeks or Ideal Months can be much more appropriate for a Swag than, say, story points

user story mapping

- arranges user stories into a useful model to help understand the functionality of the system, - identify holes and omissions in your backlog, and effectively plan holistic releases that deliver value to users and business with each release. - Once user stories are organized as per the functionality, then they are sliced into sprints with a goal to deliver a valuable product increment in a release. - allows you to form a big picture of your backlog. - to understand the backlog better to make right decisions about grooming and prioritization. - promotes silent brainstorming. Horizontally, we can find the title for each grouped functionality; vertically, the main stories/issues related to each group. The functionalities are prioritized from left (more important) to right (less important). Each group will then have the stories prioritized again vertically.

Relative Mass Valuatioin

- biggest advantage of agile is stories are estimated relative to each other, not on the basis of hourly or daily effort. - this technique is most useful when you have large backlog of stories, estimation for each of them becomes daunting -this is a quick way to go thru all of them and estimate relatively Process: 1. firstly write a card for each story and set up a large table so that stories can be moved around easily relative to each other 2. pick any story to start and ask the team to estimate if they find it relatively large medium or small 3. position them at extreme ends acc to their sizes and med one at middle and then keep taking new stories to put them accordingly 4. this way its easy to est 100s of stories in a short while, team gets sense of accomplishment after seeing the scope of work laid out in front of them and estimated in order of effort 5. assign a no to stories like start from 1, until u feel this particular story is at least twice as difficult as first one, then assign 2. The idea is to get a rough point estimate, not a precise order.

Feature

- detailed experience of how your users will do something with your application. - In order to make "something" meaningful, a Feature must include (1) the reasoning behind it, the motivation, "the goal", "the pain to solve" - without it, it's simply impossible to judge Feature's ROI in terms of value versus effort and money. Once this is in place, Feature should include (2) user flows. A user flow might be "User can click on the delete button to delete his record, this will popup [a message] for him to verify first". Usually, a Feature will be built from multiple flows, edge-cases and wording to make sure the grand experience is fully complete. To help relating flow with look & feel, a Feature should (3) include mockups and other accessories. Lastly, (4) business (and even technical) notes should be added to wrap up the experience: URL structure, SEO considerations, user messages user, analytics requirements etc.

SAFe

- framework for applying lean and agile practices at enterprise scale - most important management responsibility remains measuring improvement and ROI - requires from management to choose the solution that best fits their business model & products, and helps shorten the delivery and release phases in order to outperform competitors. -SAFe describes three levels of scale: Team Program Portfolio NINE PRINCIPLES OF SAFE 1. Take an economic view 2. Apply systems thinking 3. Assume variability; preserve options 4. Build incrementally with fast, integrated learning cycles 5. Base milestones on objective evaluation of working systems 6. Visualize and limit WIP, reduce batch sizes and manage queue lengths 7. Apply cadence, synchronize with cross-domain planning 8. Unlock the intrinsic motivation of knowledge workers 9. Decentralize decision-making - at program level - no of scrum teams at proj level working 2gdr for a proj.. - 50-125 people - these people are called agile release train - this is also timboxed in PIs (program increments) which has 5 iterations by default - product manager in form of features in product backlog - train is governed by RTE(release train engineer) who acts as trained scrum master - he is the programmer manager of program level starts with planning meeting all team members gather 2gdr to see features upcoming for PI the teams identify what all they can do.. identifies dependencies and risks with other teams then the teams commits to business users what they can expect in the coming PI so there is a biweekly meeting of scrum masters which is called as scrum of scrum then they have the demo at the end of integrated system to show all teams wrking at same pace we plan only 4 iterations the 5th one is known as IP(Innovation planning) to come up with creative ideas..hackathon n all planning- retrospection and planning for next PI IP is also used to estimate if team is delivery speed at the value stream level there are many ARTs to build bigger system solution mgnt is content authority value stream engineer is coach and guide solution architect ensure good architect is used value stream are on the same PI cadence as the ARTs and planning solution demo portfolio level is differnt yet similar program portfolio mgnt helps dictate direction for all underlying value streams by driving strategic themes from enterprise strategy and allocate budget to value streams for these strategic themes

themes

- groups of related stories. - Often the stories all contribute to a common goal or are related in some obvious way, such as all focusing on a single customer. - However, while some stories in a theme may be dependent on one another, they do not need to encapsulate a specific work flow or be delivered together.

definition of ready

- there are many partially defined items in the product backlog - this causes a lot of frustration in the team solution - teams work with the PO to agree on what defines a "ready" state of a backlog item Story defined and written Story traceable to source document (where appropriate) Acceptance criteria defined Dependencies identified Size estimated by delivery team User experience included (where appropriate) Performance criteria identified (where appropriate) Person who will accept the user story is identified Team has a good idea about how to demo the user story

velocity chart

-used to forecast - work(story points) done in a specific period of time(sprints) - we can compare the actual velocity with the velocity required to meet the deadline

Scrum Development Team

1. Cross-functional (e.g., includes members with testing skills, and often others not traditionally called developers: business analysts, domain experts, etc.) 2. Self-organizing / self-managing, without externally assigned roles 3. Negotiates commitments with the Product Owner, one Sprint at a time 4. Has autonomy regarding how to reach commitments 5. Intensely collaborative 6. Most successful when located in one team room, particularly for the first few Sprints 7. Most successful with long-term, full-time membership. Scrum moves work to a flexible learning team and avoids moving people or splitting them between teams. 8. 7 ± 2 members 9. Has a leadership role

2 artifacts

1. Product backlog 2. Sprint backlog

challenges for transition to scrum agile

1. Difficult to understand the terminologies used in Agile 2. Fast paced environment leads to, inaccurate estimates and improper requirement documents sometimes 3. For off-shore teams, communication and co-ordination can be a big challenge 4. Learning and using the Agile tracking tool can become a challenge for team 5. Due to improper documentation, it becomes a challenge for QA team to understand the requirements correctly 6. Ensuring the tasks allocation to all the team members equally 7. Prioritization of tasks, based on the dependency 8. Inaccurate estimates can leads to burn-down of engineers 9. Long and frequent meetings due to less documentation. 10. The engineers who worked in Waterfall model earlier take it as a wastage of time and they start skipping the meetings 11. Frequent changes in the requirements may lead to frustration to the engineers

Sprint Burn-down Chart

1. Indicates total remaining team task hours within one Sprint 2. Re-estimated daily, thus may go up before going down 3. Intended to facilitate team self-organization 4. Fancy variations, such as itemizing by point person or adding trend lines, tend to reduce effectiveness at encouraging collaboration 5. Seemed like a good idea in the early days of Scrum, but in practice has often been misused as a management report, inviting intervention. The ScrumMaster should discontinue use of this chart if it becomes an impediment to team self-organization.

prioritization techniques

1. MOSCOW M - MUST have this. S - SHOULD have this if at all possible. C - COULD have this if it does not effect anything else. W - WON'T have this time but would like in the future. Each requirement will have the priority which would be tagged to MSCW. "M" being the highest and "W" being the lowest. 2. Business Value based In this case, each requirement carries a business value it could potentially generate to the company. The business value would be decided either by the Product Owner or the Product owner team. The requirement with highest business value is implemented during earlier releases . 3. Technology risk based In this method, requirements are prioritized based on the risk associated in implementing it. The risk is typically based on the technology. The requirement with highest technology risk is implemented during the earlier iterations. 4. Kano model In this method, the requirements are prioritized based on the customer preferences. Attractive Basic Performance Indifferent Reverse 5. Walking skeleton In this method, the requirements are selected such that minimal carefully selected end to end features are built within a short span of time. 6. Validated Learning In this method, features are chosen based on the highest market risk i.e. some thing that is not experimented yet. Release it to the market, get the feedback and apply the learning onto the new feature

Product backlog

1. One dimensional forced ranked list of customer centric features prioritized by the product owner 2. Contains everything team might ever do 3. Anyone can add anything throughout project 4. PO will constantly re prioritize it and SM will make it visible 5. Doesnt contain tasks 6. Contains product backlog items(PBIs) 7. gets larger as development continues from sprint to sprint because every sprint review demo prompts more and different requirements 8. Items at top are more granular than items at bottom

types of impediments

1. Scrum Master owned 2. Organizational 3. Team owned Psychological Impediments: geographically distributed (have formal meetings with timelines set, time allocation set and emails and reminders), presence of people who conduct appraisals (keep them away at the retrospective meeting cuz the core of scrum is self management and collaboration) (invisible gun effect) and people jumping to conclusions.(orid technique) Organization impediment: An example of an organizational impediment would be something like, "I have a person on my team who is constantly being asked by other managers to take on other duties. As a result, he are never able to properly commit to and focus on the work for this project " So I would work with managers to remove this impediment either by: Having the person replaced with someone who had fewer distractions Having the other managers take those distracting items off his list of things to do. Scrum master level impediment: "The team has been trying to have a meeting with the tech lead from another team for 4 days now. He is hard to catch up with and his calendar is nearly full." As a scrum master I would coordinate/facilitate a face to face meeting so that the team is not consumed with administrivia. Team Level impediment: "We need to test this feature but we don't have enough testers." As a Scrum master I would guide the team to solving this themselves by "swarming" so that everyone becomes a tester so that we could get items to done.

Roles

1. Scrum master 2. IT team of 5-9 people 3. Product Owner

Product Owner

1. Single person responsible for maximizing the return on investment (ROI) of the development effort 2. Responsible for product vision 3. Constantly re-prioritizes the Product Backlog, adjusting any long-term expectations such as release plans 4. Final arbiter of requirements questions 5. Accepts or rejects each product increment 6. Decides whether to ship 7. Decides whether to continue development 8. Considers stakeholder interests 9. May contribute as a team member 10. Has a leadership role

Sprint Task

1. Specifies how to achieve the PBI's what 2. Requires one day or less of work 3. Remaining effort is re-estimated daily, typically in hours 4. During Sprint Execution, a point person may volunteer to be primarily responsible for a task 5. Owned by the entire team; collaboration is expected SMART Specific Measurable Attainable Relevant Time Bound

Baiscally 4 meetings

1. Sprint Planning meeting 2. Daily Scrum -------Backlog Refinement Meeting------- 3. Sprint Review Meeting 4. Sprint Retrospective Meeting

Product / Release Burndown Chart

1. Tracks the remaining Product Backlog effort from one Sprint to the next 2. May use relative units such as Story Points for Y axis 3. Depicts historical trends to adjust forecasts

scrum 3 pillars

1. Transparency Artifacts Meetings Information Radiators 2. Inspection Scrumboard and information radiators approval from PO, stakeholders in review meeting 3. Adaption Change requests Retrospective meetings Constant risk identification

3 types of user stories or items in product backlog

1. User Stories Brief simple statements of a desired product function from an end user's perspective. As a <End User Role>, I want to <desired action>, so that <desired benefit>. As a Personal Checking Account Holder, I want to register for an online banking account, so that I can access my account details online. As a Registered Online Banking Customer, I want to view a list of all my accounts, so that I can quickly see my current balances. 2. Non-User Stories Brief simple statements of foundational or infrastructure needed in order to deliver User Stories in the Product Backlog. As a <Team Role>, I want to <desired action>, so that <desired benefit>. As a Developer, I want to configure our assigned development region, so that we can begin developing User Stories in our backlog. As a Tester, I want to prepare a test lab, so that we have representation of all device types & operating systems we need to execute tests on. 3. Spikes Brief simple statements of research that is needed in order to move forward with other items in the Product Backlog. As a <Team Role>, I want to <desired action>, so that <desired benefit>. As a Developer, I want to research the latest security protocols, so that we feel confident we selected the best method for securing our customer's financial data. As a Business Analyst, I want to research the state specific business rules for handling white goods taxes, so that our customer's are charged appropriately for the items they purchase.

2 types of sprint planning

1. Velocity driven 2. Commitment driven

agile 4 principles

1. interaction and integration over process and tools 2. wrking s/w over documentaiton 3. customer collaboration over contract negotiation 4. responding to changes over plan

Scrum

1. light weight agile project management framework for software development. follows incremental & iterative approach 2. using one or more cross-functional, self-organizing teams. 3. provides a structure of 1. roles, 2. meetings, 3. artifacts. 4. uses fixed-length iterations, called Sprints, 15 days upto 30 5. teams attempt to build a potentially shippable (properly tested) product increment every iteration. - an alter to waterfall model 6. ability to develop a subset of high-value features first, incorporating feedback sooner. 7. new approach to increase speed and flexibility of development 8. key principle is its recognition that customers mind can change anytime during a project 9. usually associated with object-oriented software development. 10. useful for complex work involving knowledge creation and collaboration, such as new product development.

Planning Poker

1. makes sure that everybody participates and that every voice is heard. 2. each team member is given a set of cards with numbers on them. The numbers are usually ordered from 0 to 21 using the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, and 21. 3. each story is read aloud, every1 asked to hold up their card showing level of effort they believe it requires for team 4. initially scattered ans but later they all realise 5. once all votes are in, highest n lowest estimates give explanation 6. frequently, experts with detailed knowledge tell rest of team why certain story is more diff or easy than they think of it cz of unexpected requirements 7. through this process team members inc their knowledge base regarding req, clarity 8. stories with more than 20 points should be broken down

self oragnization qualities

1. members are committed to clear, short-term goals 2. members can gauge the group's progress 3. members can observe each other's contribution 4. members feel safe to give each other unvarnished feedback

types of velocity

1. planned - 2 types velocity based- total no of story points/ tot no of sprints capacity based - abilility of a particular person in terms of man hours, eg sm1 myt b a shared resource .. also used to determine no of sprints 2. initial - estimation for 1st sprint, initially it ll b high..after 2-3 sprint they cm to knw..usually its 1/3rd of planned velocity 3. optimal- avg of all previous sprint velocities 4. current velocity - velocity of current sprint

scrum artifacts

1. product backlog 2. sprint backlog 3. velocity chart 4. burn down/ burn up chart 5. Story 6. Task Boards PBI Sprint task Sprint bd chart product bd chart

T shirt sizes

1. using numbers for estimation is quite difficult sometimes, sometimes over or under estimation happens cz of nos 2. extra-small, small, medium, large, extra-large, or double extra-large 3. implied precision of numerical score removed 4. helps team come out of their analytical thought processes and into a more flexible, relative mindset. disadvantage: 1. non-numerical scales are generally less granular. While that can speed up the voting process by reducing the number of options, it may also reduce the accuracy of velocity estimates. 2. the ability to compare stories with each other can be a little bit more complicated, since there is no clear mathematical relationship between a medium and an extra-small. 3. requires extra effort on the part of the person coordinating the agile process. The T-shirt sizes need to be converted to numerical values for the sake of tracking effort over time and charting an estimated velocity for the team. so useful only for teams who are just starting with agile, later numerical techniques should be used

Product Backlog Items (PBI)

1. written in form of use cases, user stories or epics 2. Specifies the what more than the how of a customer-centric feature 4. Has a product-wide definition of done to prevent technical debt 5. May have item-specific acceptance criteria 6. Effort is estimated by the team, ideally in relative units (e.g., story points) 7. Effort is roughly 2-3 people 2-3 days, or smaller for advanced teams should have these qualities(INVEST): 1. I Independent-The PBI should be self-contained, in a way that there is no inherent dependency on another PBI. 2. N Negotiable-PBIs, up until they are part of an iteration, can always be changed and rewritten. 3. V Valuable-A PBI must deliver value to the stakeholders. 4. E Estimable-You must always be able to estimate the size of a PBI. 5. S Small-PBIs should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. 6. T Testable-The PBI or its related description must provide the necessary information to make test development possible.

"Sprint Refinement meeting" aka "backlog grooming" aka "backlog maintenance" aka "story time"

Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. Teams have found it useful to take a little time out of Sprint Execution — every Sprint — to help prepare the Product Backlog for the next Sprint Planning Meeting. Facilitator - SM Members- Team, PO, SM Time - 4 hrs Purpose- 1. Clarification of requirements 2. Decomposition of PBIs into smaller ones (epics to user stories) 3. Estimation of efforts (Various techniques:Estimation cards) 4. prioritization of PBIs (by PO) 5. comes up with acceptance criteria and definition of done(proper testing and refactoring) -no commitments are made in this meeting so everyone is given estimation card and they all reveal it at the same time and give justification after which PO clarifies what exactly is he/she is expecting.(reveals things which she didnt think of earlier) after listening to his exact requirement re voting is done to re estimate efforts PO is responsible for setting the priorities based on discussion with the team. re prioritization done throughout Result- prioritized list of PBIs

Spike

Spikes are an invention of Extreme Programming (XP), are a special type of story that is used to mitigate risk and uncertainty in a user story at an early stage OR A story or task aimed at answering a question or gathering information, rather than at producing shippable product. 2 types 1. Functional spikes 2. Technical spikes There are two other characteristics that spikes should have: 1. Have clear objectives and outcomes for the spike, estimable, demonstrable, acceptable 2. Be timeboxed 3. exception, not the rule Some user stories may require both types of spikes: eg As a consumer, I want to see my daily energy use in a histogram, so that I can quickly understand my past, current, and likely near term, future energy consumption. In this case, a team might create two spikes: Technical Spike: Research how long it takes to update a customer display to current usage, determining communication requirements, bandwidth, and whether to push or pull the data. Functional Spike: Prototype a histogram in the web portal and get some user feedback on presentation size, style, and charting attributes. Prototypes, Proof of Concepts (PoC), and story boards, Wireframes all fall into the classification of Spikes. Indications for Spike's necessity: 1. Trouble shooting: Teams failure to estimate the stories effectively. Disagreement in on how big the stories are. 2. High-Points estimates: Teams story points are high for a story that a Product Owner estimates low. This could be an indication that there is technical debt the team is working on deliver a story. 3. Patterns of difficulty: There could be a certain type of stories the team is facing a lot of trouble. There are a lot of bugs and QA items from some stories. The feedback from the retrospective shows that are difficulties in implementing the technology 4. Team speaks out: about difficulties and technical creep issues.

story points

Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort. - no specific measure of time - relative size - leverage fibonacci series - highlights larger differences - prevents premature commitments

story points over hours

Story points are more suitable in these situations because the points more accurately reflect both required effort and complexity. This is a result of points being used not only for estimation, but also as a means to measure and convey commitments and team velocity.

continuous integration

We've often experienced programmers writing code and the task working perfectly, but later, while we integrated that code with the rest of the application, we faced unexpected results. To overcome such situations, continuation integration is very much needed. It becomes more important with Agile frameworks, where the nature of delivery is incremental, iterative, and in short cycles (as in Scrum, XP, or in fact in any other Agile framework). Continuous integration is possible only through an automated process that builds, tests, analyzes, and deploys the application. This process runs with each source-code change and provides immediate feedback to the development team. Minimum human intervention in these processes results in saving time. Continuous integration also reduces the risk of delivery slippage as the development team performs testing and integration on a continuous basis. This helps us identify defects in time and take appropriate and necessary action. The integration may be daily, weekly, nightly, release based, or for testers as per requirement -- and it must be, of course, done in a continuous manner. Tools used for Continuous Integration are: Cruise Control, Jenkins, Bamboo, and Buildbot Automated regression testing prevents vampire stories that leap out of the grave.

testing in scrumSprint Planning

in Sprint Planning tester should - pick a user-story 4m d product backlog dt shud be tested. - decide how many hours (Effort Estimation) it should take to finish testing for each of selected user stories. - must know what sprint goals are. - contribute to the prioritizing process during sprint - support developers in unit testing - test user story when completed, log defects, retest once resolved - attend daily scrum - put any item that can not be completed to next sprint - develop automation scripts, schedule automation testing with continuous integration system, review CI automation results and create reports on it and send it to stakeholders - execute functional, non- functional testing - co ordinate with cust and PO to define acceptance criteria for acc tests - also does acceptance testing sometimes and conforms testing completeness for the particular user story retrospective - as a tester what went wrong, what went right, lessons learned and best practices

forced ranking

only 1 PBI should be on the top.. no 2 PBIs can be at same level or at the top.

user stories

s/w system requirements formulated as 1 or 2 sentences in everyday or business language of the user. written throughout a project. usually a story writing workshop is held at the beginning. goal is to create product backlog basically a user story talks about 1. title 2. as a (user) 3. i want to (goal) 4. so that (reason) 2 types 1. epics - a large user story, high level. these can be broken down/decomposed into smaller stories that can fit into a single iteration 2. ready stories - small detailed that can be implemented directly, tested tools used - version 1 (most famous) its about who what why not how

Bad apple theory

suggests that a single negative individual ("withholding effort from the group, expressing negative affect, or violating important interpersonal norms"14) can disproportionately reduce the performance of an entire group. Such individuals are rare, but their impact is magnified by a team's reluctance to remove them. This can be partly mitigated by giving teams greater influence over who joins them.

pair programming

two people work collaboratively on the same task on a single computer. - better communication, - better clarification of the problem, - better understanding of its solution. - The person who controls the mouse and keyboard is called the "driver." - The other person, who sits beside the driver and makes sure that solution is implemented in an effective and efficient manner, is called the "navigator." - The members of the pair can switch with other members within the team to take on a different task in another iteration. Better coding practice adherence Less dependence on particular individuals More effective inclusion of new team members Greater knowledge sharing among members No separate code reviews required Better code quality

Test driven development (TDD)

unit tests are written first, then enough code is written to make the tests pass. The pure TDD cycle is to write one failing unit test, then enough code to pass the test. Then a second failing unit test, then enough new code to pass both tests. And so forth. refactoring is one imp factor Unit Testing layer : junit, jasmine, jmock

behavior driven development (BDD)

used to calculate TDD BDD (Behaviour Driven Development) is a synthesis and refinement of practices stemming from TDD (Test Driven Development) and ATDD (Acceptance Test Driven Development). BDD augments TDD and ATDD with the following tactics: apply the "Five Why's" principle to each proposed User Story, so that its purpose is clearly related to business outcomes thinking "from the outside in", in other words implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste describe behaviors in a single notation which is directly accessible to domain experts, testers and developers, so as to improve communication apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains cheap Cucumber tool + Selenium tool Which layer? It should be E2E (End To End)

Technical Spikes

used to research various technical approaches in the solution domain. For example, a technical spike may be used for evaluation of potential performance or load impact of a new user story, evaluation of specific implementation technologies that can be applied to a solution, or for any reason when the team needs to develop a more confident understanding of a desired approach before committing new functionality to a timebox.

Functional spikes

used whenever there is significant uncertainty as to how a user might interact with the system. Functional spikes are often best evaluated through some level of prototyping, whether it be user interface mockups, wireframes, page flows, or whatever techniques is best suited to get feedback from the customer or stakeholders.