Separate names with a comma.
Recommended. Know people from your network.
Don't have an account?Sign up Now
To reset your password, enter the email address you registered with and we"ll send your instructions on their way.
Discussion in 'Agile and Scrum' started by Raj K(3066), Jul 23, 2016.
ASM Batch 23rd July.
The team name is Evangelist Intellectuals Managing Mayhem Petals
Read Scrum Guide - Foundation for Scrum: http://www.scrumguides.org/
There are more certifications with Scrum Alliance; however, EXIN covers more knowledge areas of Agile. CSM has more value in the market today but EXIN is catching up. CSM has been heard of by everyone in the market today, but ASM is catching up. https://www.scrumalliance.org/why-scrum/scrum-guide. Scrum Alliance is linked to CSM and has multiple certifications options starting at the foundation of CSM and moving up. EXIN covers more....
Three Pillars of Scrum:
Transparency, Inspection, Adaption
Benefits of Agile Development:
Higher Productivity and Reduce in Waste
Faster Time to Market due to Frequent delivery
Improved Stakeholder Satisfaction
More Options to Motivate the Team through self organization and effort
Higher Quality by establishing clear acceptance criteria and "Definition of Done."
Feature Driven Development - short iterations
XP (extreme programming) -
Rational Unified Process
KANBAN/Scrumban --- but not methodology... good for operations but not development - limiting work in progress
Lean principles and methods are used but not methodology
DSDM is methodology
Well Known XP Practices:
Metaphor (connect things for easy understanding - EX: Information Radiator, radiator is the metaphor - we know it is hot.... also burn down, the amount of work to be completed or was consumed instead of burning the floor down) Martin Luther's speech - I have a Dream, connects all the people. Powerful metaphors can drive behavior
****Refactoring - write code today and how can I improve on it.
****Collective Ownership - all of us own the code in which we write not Ranga wrote page one so he corrects it. We all do it together and we get this by pair programming.
****Pair Programming - may miss something when writing code. An independent eye can help catch errors. Examples - illegal to talk on mobile phone but not to talk to the person next to you... The other person can help you avoid blind spots or "invisible gorillas." In one hour I code for 30 minutes and then my partner takes over for next 30 minutes. We take turns and we are on the same programme.
Coding Standard - standard approved by industry on how to write the code. WordPress states Code is Poetry (structure or standard) CamelCase
Sustainable Pace @least 20 people to answer and expect to maintain throughout class.
Simple Design - eliminate waste... controls that are available to help make easy to operate such as smart phones or microwaves. USB port example, user friendly.
Whole Team - team must consist of all roles required for project, DBAs Architects, BAs all of them.
Continuous Integration - multiple components make a part of one big thing... 24x7
**** highlighted by instructor
Mix and Match like salad for agile methods to use with scrum and kanban for example.
Word customer appears in XP not scrum
Roles for XP:
Reflective Improvement ... our retrospect
Personal Safety - protect and motivate team
Focus - one iteration at a time
Easy Access to Expert Users
****Osmotic Communication - working at your desk and hear a conversation from across the desk about your project and are not aware of this information that should be coming to you but did not. Information that flows in the background, hearing of team members so you can pick up what is relevant for you. Corridor Rumors even... great for co-location team in one place. Picking up clues from when someone is speaking.
**** highlighted from instructor
2007 better defined.. Atern - highly agile bird
Early delivery enables early feedback
User engagement is necessary for getting the right business solution
Requirements revolve over time; however, time scale is fixed - or timeboxed.
Implement 80/20 rule -- Parito Theory - fix customer problems that are real pain points first.
Nothing is built perfectly first time... iteration. --- FAIL FAST, quality can improve over time.
Time and Cost are fixed, scope is variable, flipped upside down from normal approach. For given time, for given cost with expected quality what we can deliver, can change the scope according to priority .... if I cannot accommodate in this release will do next, but I wont compromise on time, cost, or quality.
IRON TRIANGLE/ATERN Triangle: I will deliver X hours of work at Y $ in Z TIME, but not telling what work I do... contract is fixed for duration only... at end of time extend contract or terminate it. Telecom companies use this especially for data packs for your duration and cost being fixed and how much you consume is up to YOU. Once cutoff date is there, the pack expires and you move to next. Scope is volatile.
Amazon Prime example versus standard delivery
Five Core Techniques:
DSDM introduced MoSCoW Prioritization: Must, Should, Could, Won't (haves)
Modeling - prototypes ex.
Example of MoSCoW for Class:
MUST: 1. Participants 2 Trainer, highly desired
SHOULD: everyone good bandwidth, headphones
COULD: More interaction, live class
WONT: all of us on audio
What if, you have to plan capacities (human resources) in the future, but you do not know yet what the requirements are, nor what the MoSCoWs are...How do you still plan sprints or planned resources?
Iterations/sprints never end. In real life we have contracts and fixed time. Somehow upfront planning. Product development is never ending.
by concentrating on basic features, you satisfy the customer much quicker - SO FASTER ROI, what Agile does.
Decide as Late as Possible
Empower the team
Deliver as Early as Possible - JIT
Build Integrity and see the whole
WASTE in SOFTWARE DEVELOPMENT:
Task switching - working on two things... waste
Partly done work
Pull system, work gets pulled into the system and by the suceeding system not pushed by preceeding step
Great in manufacturing. Example - Marriage Dinner - food is pushed. Buffet is like KanPan we pull from buffet we go and take what we like and it is self-service.
Waiting is nothing but waste. Customer satisfaction is must better because they are pulling and deciding what they want to work on.
Kanban is good for maintenance and repetitive tasks - maintenance tasks... operations... ITSD tickets
The Theory of Constraints
a Book: The Goal by Dr. Eli Goldratt
Create flow - minimizing WIP we are minimizing Waste
Continuous improvement or KAIZAN
Dev team want changes, maintains as long as there is work.
Operation teams want stability - Maintains if systems are working and sustain
Do releases quarterly, yearly etc.
Development done 1 month before, has to wait because a release is not ready. A release is getting Code into production.
Dev collaborates with Ops upfront for efficient trasition throught life cycle
DEVOPS is integration between Developer and Operations
Release is getting code into production
While waiting waste is getting created and time to market is increasing… delaying… lose opportunity forever.
In Dev Ops we are doing Continuous development à continuous integration à Continuous Deployment.
Speak about Non Functional Requirements: The system must complete 98% of transactions in 2 seconds. Important operational statistic. And Every Friday, after business hours i.e. 9.00 PM. all transactions must be backed up. Happens behind the scene. Example statistic -- Amazon does about 1000 production deployments in a day. Development, Testing, Deployment is required.... Automation and Culture and Applications and Technology and mindset for DevOps. make dev and operations teams to work together. DevOps - when engine is running. Dev likes to bounce the servers but ops doesn't want you to. Operation success, patient dead - doctor is only learning. Only possible when automation.
Operation Team - who maintains live systems. Working software goes into production much faster.
How does ITIL and Agile work together
Information Technology Infrastructure Library - UK
1. Service Strategy
2. Service Design - Customer Experience Design. Example is Apple Stores (have same look and feel up front are phones and organized the same- service is hidden from front, may make customer think issues). IVR before Call Center
3. Service Transition - handover DevOps - integrate the teams... ITIL gets integrated with Scrum.
CSI - continually service improvement... potentially ship-able product is between 3 & 4...
4. Service Operation -
*****ITIL and scrum work together across entire life cycle
Refer to Integrating Agile Roles to ITIL Roles
Customer Feedback, then adapt, CI (continual integration) build a system where validation is done by customer and feedback is provided to organization immediately.
Pizza Video: Should not have lack of trust with lock and key... could also increase in cost, then problem on who should have the key.
Eliminating waste: Software Dev. Project and approval process is time consuming and causes delays. Everyone leaves at 5:30 and a decision is needed post 5:30 PM, delegate or automate? Automate through (1) continuous integration can solve the problem for us. 2. Build prototype and share with customer
*Inspect and Adapt - hired Chinese speaking person to work with them for better customer collaboration
Solutions - mix of best of all, salt according to taste for different methods and advantages
Scrumban, ScrumButt (doing everthing but not Scrum - very popular)
Iteration and Sprint = interchangeable. 3 events
3 Roles in Scrum:
1. Product Owner
2. Scrum Master
3. Team Member/Team
** No other roles - so no room for PM but PM can play SMaster
Someone has a vision - Assumption before project starts. What the product owner wants to achieve. To make vision realilty we need product output and $$ is also involved and someone has funded the project request.
First thing we do:
1. Product Backlog - all the work we are supposed to do functional and non functional like BRD written by Product Owner in format of User Stories
PO is from the business, the business goals to achieve and help guide. If you have work provided not in product backlog you do not work on it and defer to PO. the PO is the SPOC or single point of contact. PO uses the Product Backlog as a heat shield from stakeholders otherwise dev team will be bombarded. List is Prioritization - by PO, highest priority will be on top.
2. Sprint Planning - the team and PO with the facilitation of the SM take the product backlog with prioritized items at the top.. in order to create the SPRINT BACKLOG.
*First thing we do is determine how long the sprint should be. Sprint planning is mandatory for all sprints. Should be no longer than 4 weeks. Duration of sprint is 2-4 weeks. No limit on number of sprints. Sprints never in as per the book but in real life they are limited by your contract.
NOTE: Each sprint has its own backlog... derived from the product backlog/Mother backlog.... small children are created for events/sprints. Bucket of capacity should be easy to calculate because we are assuming 4 weeks for sprint and highest business value items. Understand how much work we can take on is determining the capacity of the team. Sprint backlog ends up becoming what the team commits to from the Product Backlog for 4 weeks.
Takes sprint backlog into your 4 weeks worth of a sprint. The sprint is LOCKED.. It's frozen once sprint backlog is created and approved. It's FIXED. Team can change Sprint Backlog only. Outside influences cannot change or stop the current sprint. Any interruptions go to product backlog. Freeze the sprint backlog as a mandatory step.
Every 24 hours we do a standup or daily scrum
1. what did we learn yesterday
2. what are we learning today
3. do we expect any issues
2 events/meetings so far: Sprint Planning, Standup
2 Deliverables/Artifacts so far : Product and Sprint Backlog.
Standup is a commitment meeting - commitment to the team (all accountable). If a problem comes along or impediment the scrum master works on clearing roadblocks and removing impediments. Meetings are facilitated by scrum master. 15 minutes for daily standup. every day same place every time, 15 minutes, and team participates PO can participate as required.
At the end of the sprint, potentially shippable product (product increment) - not building in one stretch.
Stuff team took on from product backlog into sprint backlog is DONE, done, DONE.
Now the people on the outside can be shown what is completed... in a SPRINT REVIEW (3rd meeting) which is show and tell to outsiders and stakeholders and show them the actual product so they can see the actual progress to the whole product and they can react to the product. Then outsiders go away and the team comes back to do a RETROSPECTIVE: lessons learned with a purpose. Did we reach or acheive our goal and objectives. Stuff we are going to change on HOW we work together - where we inspect our process on how we work together. Cyle of continuous improvement. Creating, Inspecting, and Improving the Product and Creating, Inspecting and Improving the Team!
3 Roles: PO, SM, Team
4 Events/Meetings - facilitated by SM: SP Planning, Daily Stand Up, Sprint Review, Sprint Retrospective
2 Artifacts: Product and Sprint Backlog
Team, attached to thread are my highlights/notes from reading the "Scrum Guide." This is something I will need to read again and again. Definition of Done is an issue at my organization who is brand new to Agile/ and Scrumbutt.
Certified Scrum Master is a certification for "Scrum Master", are there any other certifications which the Team or a Product Owner can take? This is to create a "Scrum Knowledge" team.
@Trupti Deshmukh , for Product Owners, there is certification.
Scrum Alliance offers Certified Scrum Product Owner CSPO Certification.
Scrum.org offers Professional Scrum Product Owner PSPO.
To get a head start, you can check out this awesome book:
Hello fellow Agilists,
Please find below a High Resolution Image of Agile Methodologies at Glance. Created by Yours truly to assist you for ASM exam preparation.
To download, you can right click on the image and select "Save As" option. If you like the image, let me know !
For a comparison of all these methods, which might be useful for your knowledge and exam preparation, check out this link:
Thank you for the Agile Methodologies at a Glance. You did a great job on this! I was able to successfully save and will try a couple of print options. Thank you also for the link to the methodologies comparison article.
Raj is there a way to print your embedded picture?
Raj, Great note for reference of the key words..
Class 3( some notes missing as i missed last part of the class- will add the images)
value of the out of the work changes from person to person
Food needed immediately cannot help out with 5 star which is far off.
Need a quality time with important person could not be sought in street and it is can only be found in the 5 Start
Minimum Valuable(Viable) Product
Every release should deliver a Minimum Valuable Product.
Agile is value driven and not effort driven.
Scope describes the deliverable which say the value
It is broken down
Makes estimation easy and helps in Story making
Epics are Backbone and they are only defined by Values.
Epics is collection of User Stories and contains Features
Tasks are the lower levels and are spoken with team.
EPC broken down to Modules(Features) and further broken to User Stories further broken to Tasks
User Stories are the building blocks of back log. (Release or Sprint)
Prioritization is done in agile to deliver values faster to the customer i.e. Workable solutions
This is the backbone for planning
Critical path is addressed by time box in an iterative approach.
Agile is non - predictive i.e. Inspect and adapt
3 C's (Also used for testing acceptance)
Card - Should be possible to write in a card. This comes from PO
Conversation - User story card should be possible for team and PO to discuss and agree on same page to develop for the End Product. This happens between PO and Team.
Confirmation - Should have acceptance test. Happens between PO and Team.
Card User story Format -
As a (user) I want (requirement) so that (benefit)
e.g. As a "ASM Learner" I want "the classes to be more descriptive and should have more examples " so that "we can imply and relate to the practical items. "
A user story is something which meets the 3Cs and should be Independent Negotiable Valuable Estimable Stable Testable(INVEST).
Independent - Each user story should be independent and result in working software.
Negotiable - Open for discussions between PO and Team
Valuable - Each user story should have a value for the customers.
Estimable - An user story should always be estimate able.
Small - User story should not be so big to make it tough for Prioritize, or create Task or plan with certain level of certainty.
Testable - User story or its description must provide the necessary information to make the test development possible.
Use cases are documents describing functional flow of a user with a system
Epic--> Modules -->Use Cases --> Multiple Use stories --> Test cases to support user stories
Agile uses Fibonacci sequence and tasks are estimated in Hours.
Estimation is done with consensus or with the highest.
Road Map or Release Planning
Prioritize high level Epics and determine goals
Goals assigned based on market demands, regulatory needs, and customer expectation
Each release should
Estimate Target stories
Repeat till target stories are assigned
Use the iteration length
Assign Stories based on iteration
Iterate till stories and release date are met with user satisfaction.
Not too much to be included in release backlog.
Ideal Time -
Amount of time it takes to complete a piece of work
Based on the notion of - team members are available to do the work and no distraction.
Converting ideal to Elapsed time = Depends on the distraction and excluding the distraction.
Only actual time is considered, not the distractions.
Thank you SOOOO MUCH! I appreciate you taking notes this time. I was finishing mine up and these look great. I will try to combine ours together and repost!
Hi Team - I expanded on Pranab's notes and here is a combined set of notes between his and my own. I am unable to attach a PDF or Word doc of my notes. It states the file is too large. If you want a copy maybe I can send to you via email if you connect with me on LinkedIn. CHEERS. I will work on my notes for Class 4 tomorrow. It's getting late now for me here in the US.
The value of work changes from person to person. Example: Food needed immediately otherwise you will faint makes fast vending food in a street cart a valuable choice since a 5star restaurant may be further out with waiting. On the other hand, if you need quality time with an important person, this quality time cannot be sought in the street but found in a 5 star restaurant.
Minimum Valuable (Viable) Product - Every release should deliver a Minimum Valuable Product. Agile is value driven and not effort driven. All releases should focus on:
1. Minimum Valuable Product
2. Try to satisfy the customer by continuous improvement
a. Effort in building a deliverable does not mean more than the value it provides. Us as customers do not value the effort it takes to build something but the value in the features it provides only.
3. Every project will have some type of scope
a. Scope is always broken down
b. The level you are getting down to, has two advantages which will occur:
i. Your accuracy improves
ii. Estimation is a bit easy at the lowest level because we have more information.
c. This is what we call Story Mapping.
The Harry Potter series and the Bible are considered examples of an Epic. As you get to a lower level you will get to the level of detail, day-to-day planning, and tasks.
We can come to a shared understanding using a story board. A story board allows the PO to share the value with everyone. A shared document such as a charter or PDD never results in shared understanding because everyone’s perception of the scope or vision will be different.
1. Release Planning
2. User Stories
4. Sprint Planning….
· All four items shown in a story board are dependent upon the stories the team should deliver.
· After building horizontal first, we take an epic and break it down. This is a group exercise that must be done together.
· The backbone is important, a working skeleton, and slowly we will add the “flesh,” or detail. Remember the nuts and bolts are at the lowest level.
· Value is not = hours or days, but somehow we have to connect them together. The story map is the system in which you are going to produce or SCOPE.
· Epics are collections of User stories. These User Stories describe Features (2nd Level). Tasks are at the lowest level and spoken with the team.
User Stories are the building blocks of a Product/Sprint backlog. Prioritization is done in agile in order to deliver value faster to the customer i.e. working solutions. This is the backbone for planning. The critical path is addressed by a time box in an iterative approach. Agile is non-predictive i.e. we inspect and adapt, therefore empirical.
Business Vs Technical Language
User stories are building block of your product or sprint backlogs.
(Business Level) Scope à Epics à Modules à User Stories à Tasks (Technical Level)
This is an example of how we build a story map in order to work toward the first release.
1. Deliver value faster to the customer, we try to run incremental, what can I give you quicker yet faster so you can start using it.
2. Prioritization is backbone for planning (PO)
3. The Critical Path is based upon longest duration and is eliminated because we start with higher risks first and they are time boxed.
Agile Example: Driving from point A to Point B, we adapt to traffic flows. Agile is empirical – means we inspect and adapt.
Waterfall: Is like a Horse with eyes closed à focused on one direction.
Prioritization should be done by the Product Owner because they are the ones taking on the benefit or value.
The Project Team asks the PO to prioritize and the PO should come from the client because it is business who funds the project.
There are 3 C’s associated with User Stories:
1. Card – The user story should be able to be written on a 4 x 6 index card. The user story (card) comes from the PO.
2. Conversation – The User Story should allow the team and PO to discuss and have consensus on developing the product end-to-end. This conversation happens between the PO and team.
3. Confirmation – Happens between the PO and Team on what they will commit to. The Confirmation is in the form of your acceptance criteria and definition of done which is written on backside of card.
Card User Story Format
As a <user>, I want <value/requirement>, so that <benefit>. Example: As an ASM learner, I want the class to be more descriptive and contain life like examples so that the learning can be related to practical items.
User Stories should follow the INVEST acronym: The Invest theorem is from both sights, PO & team.
1. Independent – each user story should be independent from one another and result in working software
2. Negotiable – open discussion between the PO and team, if unable to tackle something in one sprint negotiate for a later.
3. Valuable – each user story should provide value and output to the customer. The team has to understand what the value is from the customer’s view.
4. Estimable – user stories should be estimable --- affinity estimation - how long it takes, in story board it’s the task level
5. Small – user stories should be small enough so they are easier to prioritize and create tasks or plan with a level of certainty while thinking big picture.
6. Testable – user stories or their descriptions must provide the necessary information to make test development possible. what cannot be measured cannot be tracked, if you cannot test it how can you deliver it.
Use Cases describes functional flow. Epics à modules à use cases à multiple user stories à test cases to support user stories. The most powerful questions start with why. Agile uses a modified Fibonacci sequence and tasks are estimated in hours. Estimation is done by consensus or majority vote preferably the former. The modified Fibonacci sequence looks like this and again is estimated in hours: 0,1,2,3,5,8,13,21 and plays a role in planning poker.
We try to group user stories based upon their value. Value can be arrived based on its complexity and we group user stories into business value
The next step is to group the user stories into a relative scale such as
· Large = 20 roughly 2 times more than high
· Medium = 12 roughly 3 times more than low
· Low = 4
An affinity estimation example is used to make the determination if you can fit your car through two other objects in front of you, doubtful you could clear. Another example is t-shirt sizing = S,M,L,XL,XXL. Another example is rating your skills on a scale of 1-10 (relating your skills to others). In school marks and ranks are worse compared to grades. Grades are affinity estimations. Business value is the value in each user story expressed in “numbers” which are given only by the PO. Affinity – Relative sizing could be:
· Highest = More Value
· Lowest = Less Value
· 1,2,3 or 10,20,30… but should be RELATIVE which means medium effort should be more than small etc.
Closer to the target is the most important, not hours or effort. Target story points because value is calculated as a story point.
When discussing user stories, we unlock assumptions and get granular understanding. The team will own the hours (estimates for user story tasks) as we practice collective code ownership (XP) and accountability.
Adding up all the tasks for story points, you are typically using hours with cards. You don’t show your cards to the team until told to flip over. This is the process of estimating user stories which are requirements. Acceptance criteria and the definition of done must be included and understood. During planning poker you need to achieve consensus first and then majority may rule if stalemate.
Sprint Planning: Example subset of product backlog of stories pulled to planning meeting:
All team members will meet with the PO who will present a prioritized subset of the product backlog.
The team chooses the highest business value = 40 in this example. The team estimates the story to be 8 hours. Story points are not estimates but represent a relative way to express value.
This second 40 point user story is estimated at 24 hours
Once we reach capacity we try to look for smaller items such as bringing over a story with points = 25.
· The result is the three user stories depicted above are now in the sprint backlog and are committed by the team if assuming a one week sprint. Our Ideal Time Example is calculated off of 1 week iteration.
· There is a 5 member team / 200 hrs per week. If you have a 2 week sprint, you then have 400 hours per week.
· Out of the 400 hours actual hours you taken into account disruptions, meetings, etc or use a ration of time and then the team will take on user stories to fill the hours allocated as work comes in. 400 * .8 = 320 hours – work on the higher priority items first.
Example: Fill in big rocks first, then smaller ones, then sand…
Velocity = is a measure of user story values delivered per sprint/iteration. If a lower story has dependencies on the higher story, you would need to try to split the stories if able or take out the dependency and make a new story. Velocity is calculated for sprint and releases.
Actual Velocity is calculated only for completed user stories which complete are defined by a Definition of Done.
Velocity helps the team understand how much business value can be delivered in one iteration.
The team had a planned Velocity of 105; however, team successfully only completed 65. There are 550 total backlog value points, how much will left on the burn down? That means we have 485 value points to tackle and we are essentially “behind schedule.”
User Story Mapping
Product Backlog and Sprint Backlog
Road Map or Release Planning - Prioritize high level EPICS and determine Goals
Goals are assigned based upon market demands, regulatory needs, and customer expectations. Each release should:
· Estimate Target Stories and Repeat until target stories are assigned to sprints.
· Use the iteration length (sprint length)
· Estimate Velocity
· Assign Stories based on Iteration
· Iterate until stories and release date are met with user satisfaction
· The amount of time it takes to complete a piece of work
· Based on the notion of team members are available to do the work without distraction
· Converting ideal to elapsed time = depends on the distraction and excluding the distraction
· Only actual time should be considered not distractions.
Ideal Hours vs Elapsed Hours
· By definition, what is our class time limit = 4 hours
· How long is our break? 15 minutes
· Poll is 3 Minutes in length
· Actually only learning 3hr 42min assuming no disturbance for us = Ideal Time
· Elapsed time = actual time which is 4 hours
· Total Duration in the flight example is IDEAL TIME. We must start from home which starts the journey and go through check-in etc. This is Actual Time. The difference between ideal and actual time = waste.
Team I have class 4 notes prepared. If you would like a copy, please locate me on linked in and send me a message. There are too many pictures to post for the thread and I cannot get a PDF to upload (not enough space).
I received my Mike Cohn book Succeeding with Agile as recommended by Raj. I'm currently on chapter 2 - middle of ADAPT. This book is a text book in nature; however, it helps with the exam from what I am told.
I can see this book being a huge benefactor in raising Awareness in organizations that change is more than likely inevitable.
While not an agile book, the book Switch by Chip and Dan Heath is a great complement to this one.
Can anyone share me details about ASM certification examination procedure?
I would like to know more as well. I will take on this task. I started poking around on the EXIN site. I'll let you know soon. Also you can email me at Jenna.Ware@hancockbank.com so we can stay in touch.
Hi Team - I've taken the practice simulation test 4 times and finally made a 100% but had passing grades each time. I saved down a copy of the questions and answers for Simulation test 1 if you would like to get a copy. EXIN also has a practice test. I am going to work on Simulation 2 tonight.
Hi our friend Raj,
Can you provide us any other example tests we could practice with. The simulation test taken 4 times has really helped me obtain better idea of the concepts.
Find attached few practice questions. Checkout this site also for few more.
I would strongly recommend reading "Succeeding Agile Software Development with SCRUM" by Mike Cohn. Lot of questions come from this book. Make your own short notes of important points from this book.
In the Practice exam 1, a question
Michael is a DBA and serves five Scrum teams. All the teams have equal need for his time and he also needs about half his time to perform maintenance and tuning on production databases. What is the best way to split up David's time so that all the teams are able to work with him?
A. Michael should spend one Sprint with each team while taking care of his routine activities
B. Michael's manager should be part of the Sprint planning for the five teams and prepare David's schedule accordingly
C. Michael should spend a day with each of the Scrum team during the week and, may be, half a day on the maintenance activity
D. The teams should block Michael's time on his calendar based on their need
The answer as displayed in the results is
Correct Option: A
It is clear that Michael needs to slice his time. Random and ad-hoc time slicing will reduce focus and productivity. Also, it is probably not reasonable that a team can do without his services for several sprints in a row. So the best approach may be to devote a day for each team, scheduled in advance so that teams as well as Michael can plan around it.
Based on the explanation, the best answer would be B. Can you please clarify?