Scrum Software – Flashcards
Unlock all answers in this set
Unlock answersquestion
What are the scrum roles and how are they defined?
answer
(1) Product owner - Person who has the "big picture" goal for the end product (what will be developed) and in what order it will be developed. (2) ScrumMaster - A person who's responsible for helping the scrum team continue to improve its scrum process of development based on scrum framework. (3) Development Team - A team of 5-9 people who determine how to complete for what the product owner has asked.
question
What is the product owner responsible for?
answer
The finished product of the scrum team; thus, he collaborates with scrum master and dev. team often. This person is a main interface between the client and the rest of the scrum team.
question
What is the scrum master responsible for?
answer
The scrum master helps the scrum team build its own scrum approach and ensures that the scrum process continues to be efficient. The scrum master is between a very experienced developer and an experienced scrum member.
question
What is the dev. team responsible for?
answer
It is a diverse and cross-functional collection of people with different skills who design, build, and test the desired product.
question
Describe the steps of a scrum sprint
answer
1 Product Backlog is groomed throughout 2 Sprint is planned by the scrum team 3 Sprint backlog is created by the dev. team 4 The sprint is executed, and a daily scrum is performed 5 "Done"...a potentially shippable product increment 6 Sprint review is performed (product feedback) 7 Sprint retrospective is performed (scrum process feedback)
question
What is the product backlog?
answer
This is a groomed (read: prioritized or ordered) set of features, bug fixes, improvements, etc. which is created and prioritized by the product owner, who does research with stakeholders to gather backlog items. The size of these items is ranked on a relative scale in story points (i.e. relative to other items on the list with knowledge of past products), and it is detailed more over time.
question
What's a sprint?
answer
A sprint is a timeboxed (fixed start and end date) cycle during which a potentially shippable product is produced as a result.
question
What happens in sprint planning?
answer
The dev. team selects a certain number of PBIs to be implemented in the sprint from the product backlog, breaks these down into tasks, and time appraises these tasks. Ideally, the dev. time will be able to dev. at a comfortable pace and push out all the features selected. A time appraisal (in hours) of each item selected off the product backlog is performed, and while time remains (hours available), more product backlog features are selected and planned. Planning takes usually 8 or less hours, depending on sprint length.
question
what's a story point?
answer
A story point is an agreed-upon relative unit of how long something will take. Usually story points are assigned to a task for a PBI and averaged across the team.
question
What happens during sprint execution (& daily scrum)?
answer
During sprint execution, the dev. team, led by scrum master, completes all task-level work necessary to finish the sprint backlog. At the daily scrum, where pigs (essential members) and chickens (non-essential) may attend, the pigs stand and answer three questions about standing of current development. From there, a team may gather after to further discuss issues brought up
question
When has a potentially shippable product been created (considered "done")?
answer
This is defined as the dev. team has completed all the work it agreed to in sprint planning. It increases the confidence that the work completed is of good-quality and potentially shippable (i.e. no desiging, building, or testing of these features is left undone).
question
What happens during sprint review?
answer
During sprint review, the product development is analyzed and adapted between the scrum team and non-scrum members. This is a chance for the scrum team to see other sides of the dev (i.e. business & marketing) and vice-versa.
question
What happens during sprint retrospective?
answer
During sprint retrospective, the scrum team reviews the scrum process itself, analyzing inefficiencies in the process and what should be ammended for the next sprint. Team answers what is and isn't working from the scrum process.
question
How similar is development seen to manufacturing?
answer
It is relatively dissimilar in the fact that it is not a well-defined, rigid process for which all variables are known in the beginning. Development creates a recipe for a unique product.
question
What is the process structure?
answer
Iterative (each sprint builds/learns from the last) and incremental (new features/fixes/improvements delivered) development.
question
How does agile development handle change?
answer
Agile seeks to leverage change through inspection, adaptation, and transparency.
question
How is uncertainty managed?
answer
Uncertainty is managed by reducing all uncertainties simultaneously (reduce the whats and hows)
question
How is decision making handled?
answer
Options are kept open, so an original plan doesn't get in the way of the right answer which may emerge later.
question
What is assumed about getting it right the first time?
answer
We assume we cannot get things right up front.
question
What is the difference between exploration and exploitation?
answer
Exploration buys more information through research or prototyping; exploitation uses what is known in the beginning and assumes what isn't.
question
How do we handle change?
answer
Change is embraced in an economically sensible way throughout development.
question
How is predictive and adaptive work balanced?
answer
Some predictive work is done up front with some just-in-time adaptive work coming in later.
question
How are assumptions made?
answer
assumptions are validated (either as correct or incorrect) early and often through tight feedback loops.
question
How is feedback handled?
answer
feedback happens in multiple concurrent learning loops (daily in daily scrum; after each sprint; etc)
question
How fast is feedback given?
answer
Workflow is organized around getting fast feedback.
question
How much work is completed withing a sprint?
answer
Smaller, economically sensible batch sizes are used throughout sprints.
question
How are WIP (work-in-process) handled?
answer
Inventory is recongized throughout sprints and it is managed to achieve good flow.
question
What is preference for people over work waste?
answer
Focus on idle work, not idle workers.
question
How is the cost of delay handled?
answer
It is always considered in making decisions about development.
question
How is progress measured?
answer
Measured by validating working assets in increments.
question
What is centric?
answer
Value-centric: valuable product output is king.
question
How fast is development?
answer
Fast, but not rushed.
question
When is quality built into the product?
answer
From the beginning as opposed to mostly at the end.
question
How much formality is employed?
answer
Minimully sufficient for the product.
question
What defines a sprint?
answer
A sprint is the heart of the scrum framework, in which planning, execution, retrospective, and review take place. It is a timeboxed period during which a potentially shippable product is delivered according to a definition of done.
question
Why timebox a sprint?
answer
Timeboxing, establishing a start and end date to a sprint during which work according to "done" will be delivered, is beneficial.
question
Why make sprints short duration?
answer
This ensures ease of planning, fast feedback, bounded error, improved return on investment, rejuvenated excitement in the project, and frequent checkpoints that matter.
question
Why keep "normal" sprints (i.e. typical circumstances surround the sprint) at same length?
answer
Keeping sprints at a fixed length reduces overhead and allows the scrum team to achieve a development cadence.
question
What is a sprint goal?
answer
A goal that describes the business purpose and value of the sprint, typically focused to a single end, but may at times be multifaceted.
question
Why is it good to NOT make goal-altering changes during a sprint?
answer
This voids a mutual agreement between dev team (will get agreed upon work done within timebox of sprint) and product owner (will not make goal altering changes to this work).
question
What does potentially shippable mean?
answer
This means the team is in a state of confidence that what got done during the sprint is actually done. For example, features are tested and integrated fully, and if business wants to ship, it can ship.
question
What is the definition of done?
answer
The definition of done is a checklist of things to be accomplished for work done during a sprint to be declared potentially shippable. This should be robust enough to give the dev team high confidence that what it produced is "potentially shippable" and doesn't carry technical debt.
question
How does acceptance criteria (conditions of satisfaction) differ from done-criteria?
answer
done-criteria is more general, applying to all PBIs for the sprint, whereas acceptance criteria is more specific, having acceptance criteria specific to each PBI.
question
How do scrum requirements differ from traditional product dev requirements?
answer
Details of requirements are negotiated through conversation throughout development just enough for teams to build and just in time. Scrum views requirements as weighted, dynamic, manipulatable business goals, such that low-value reqs can be dropped if needed. Scrum treats PBIs as broad, high-value requirements which get refined and detailed over time. Many teams represent their PBIs as user stories or use cases.
question
Why use conversations instead of traditional written requirements?
answer
Using dynamic conversation to generate just-in-time requirements at a detailed-level is more effective than static, up-front writing.
question
What's the benefit of using progressive refinement for requirements?
answer
Using progressive refinement, to define the details of broader requirements throughout the development process is more adaptable to change and economically efficient.
question
What are user stories?
answer
They are a convenient, brief representation of the business value of a PBI. These user stories are good for many PBIs, but may not be good for all (e.g. fixing defects). They may follow the format of the 3 Cs (Card, Conversation, Confirmation).
question
What are the three Cs in detail?
answer
Card: On one side of the card, a user story is written in the format "As a , I want to so that ." It is a placeholder for a more detailed conversation about this goal in the future. Conversation: The conversation(s) which take place because of a card should be tailored to clarify the requirements of the user story. These conversations may reference articles, produce sketches, etc. Confirmation: Each user story will have some confirmation reqs (conditions of satisfaction) . These might be written on the back of the 3x5 card from earlier. These enable a testing team to automate these higher-level tests. This is someitmes called acceptance-test-driven-development.
question
At what level of detail are user stoires produced?
answer
Stories are produced at multiple levels of detail, and doins so is useful for planning at mutiple abstraction levels and to progressively refine big items into small items over time.
question
How do we know if stories are structured well?
answer
Well defined stories follow an acronym : INVEST (independt, negotiable, valuable, estimatable, sized appropriately (small), testable).
question
How are nonfunctional requirements added and what are they?
answer
Nonfunctional requirements are system-level reqs (e.g. works in IE, chrome, and FF on latest version). It is nice to add as many of these as possible into the definition of done for all stories developed, this way fast feedback is maintained.
question
What are knowledge acquisition stories and when are they useful?
answer
A knowledge acquisition story is a story created to buy some type of information through exploration. They are useful when the team is halted from making progress on a feature, because of a lack of knowledge AND the cost of undoing the work by making a guess and redoing the work elsewhere (feedback/adapt) is more costly than buying the information which would enable the work to be done.
question
How to user stories come into existence?
answer
Either through user-story-writing workshops or story mapping, user stories can be created at the time of high-level (release level) planning.
question
What kind of PBIs exist in the product backlog?
answer
The variant forms of PBIs include features (new functionality), improvements (to existing functionality), technical improvements, bug-fixes, and knowledge-acquisition work.
question
How can we evaluate our product backlog?
answer
We use the acronym DEEP: Detailed appropriately, Emergent, Estimated, and Prioritized.
question
Why detailed appropriately?
answer
The product backlog (items) must be detailed appropriately at the right times. If the product backlog items are all detailed up front, we may be wasting time on features we never develop. If the PBIs are detailed too late, we're slowing down the team. Thus, we want to break down large stories just-in-time (low in the backlog), say, right before a sprint (when they rise in the backlog).
question
Why emergent?
answer
The product backlog is dynamic. The product owner is responsible for taking changes into account after the sprints and adding or deleting items from the backlog as new information emerges. As new info emerges, so should items on the product backlog and the product owner needs to rebalance the PB.
question
Why estimated?
answer
We want to estimate more detailed items as they rise in the product backlog and become near sprint-ready. Estimating is a key component in determining the priority of a PBI. Thus, we need to estimate the priority of PBIs high in the PB. On the other hand, we don't want to waste time estimating anywhere past the next release. So only the items planned for the next release will be estimated (in story points/ideal days) in most cases, and others may be estimated more relatively, like in t-shirt sizes.
question
Why prioritized?
answer
The PBIs should be prioritized, because we want to work on the most critical/desirable components of our application that we can at the time. For this reason, the product backlog must be kept in a prioritized state. As with estimation, we probably won't waste time estimating anywhere past the first release, because we may never build that stuff, or that stuff may change, who knows this soon?
question
What are the principal activities involved in "grooming"?
answer
The principal activities of grooming are adding/refining (breaking into smaller) PBIs, estimating PBIs, and re-prioritizing PBIs.
question
Who does the product grooming?
answer
In the end, the product owner is responsible for product grooming. That being said, good scrum implies the product owner includes internal/external stakeholders, the scrum master, and the development team too, along the way. This leverages combined intelligence as well as bridging the business/technical gap and streamlining everyone's understanding of requirements.
question
How much time should be allocated to grooming?
answer
As a general rule, 10% of sprint time should be dedicated to grooming.
question
When does grooming take place?
answer
To an extent, grooming will take place during sprint planning, sprint review, and sprint retrospective. However, additional grooming typically takes place throughout the sprint (e.g. after daily scrum, at scheduled "grooming" time in week, or ad hoc).
question
What is the definition of ready?
answer
Like the definition of done, the definition of ready is a threshold for a PBI before it can pass into the "ready" state (ready to be executed). This may be in the form of a checklist which applies to all PBIs before they can be considered ready to be executed during a sprint.
question
How is the PB managed for good flow in releases as well as sprints?
answer
The PB is managed for good releases by separating the PB into 3 partitions of PBIs: must-haves, nice-to-haves, and will-not-haves (for specific release). For good flow in sprints, the PB must have a certain number of ready-to-go (detailed, testable, understood) items which it can pop off the stack. For most teams, a good rule of thumb is to use 3x the amount of PBIs that they normally accomplish in one sprint.
question
Which and how many product backlogs should we have?
answer
As a general rule, one product to one proudct backlog tends to work pretty well. However, this has its limitations. For example, if the application is a suite of apps (like MS office), do we create PB per app, or for the whole app? Generally, where possible, sticking with one PB for one product, even big ones, is good where possible. However, for huge projects it's just impossible and inefficient in certain scenarios.
question
How can a product be developed with multiple component teams working on each feature of the product?
answer
We can have one huge product backlog which encapsulates the 10,000 ft view of the product with very large-scale features. From there, area backlogs would be kept for separate area teams. For example, in creating the android OS, an area team might exist for the phone application, another for the browser, yet another for the menu and settings, etc, but all the high-level featuers exist in a master product backlog. These are managed by a chief product owner. Another method is to use the many teams to one PB approach. In this case, each area team would look only at parts of the backlog containing PBIs which it prefers to do next (if teams aren't interchangeable). If teams are interchangeable, obviously teams could just pop the next high-priority item off the PB stack.
question
if one team wants to develop multiple products (with, incidentally, multiple PB stacks), how should the team go about doing this?
answer
One team can develop multiple products (with multiple PBs) in a few different ways. First, if possible, the team could split into subteams, assiging one or more subteams to each PB stack. Second, if possible, the team could work on one PB stack per sprint. Third, if possible, the team could work in parallel on one PB stack which is an amalgamation of the multiple PB stacks throughout the sprint if absolutely necessary; however, the team should still work on one set of PBIs at a time. This also means that the product owner will have to combine the separate PB stacks for each product into one PB stack, which may require more time.
question
Explain the three different levels of estimation, when these are estimated, and the metric used.
answer
At the highest level, estimation occurs in the portfolio backlog. A company typically maintains one of these in an ongoing process to keep a handle on every product it's building; the company may choose to estimate these projects in terms of t-shirt size (say, S-XL). At the next level, work is estimated in the prouct backlog on PBIs. These PBI estimates may be made at the onset of product development and then during planning meetings called by the product owner in a sprint. The metric used here is story points or ideal days. These quantities represent the relative size of one PBI to another in terms of work required. A benefit of having these is the discussion they generate at the meeting when asking the team to put a number on work required. The final level of planning happens at the task level, where the team breaks up the work into number of effort-hours required for tasks within each PBI. These hours aren't actual elapsed hours, however.
question
What are the 4 essential concepts of PBI estimation in scrum? Briefly explain each.
answer
The 4 essential concepts of PBI estimation in scrum are estimate as a team, estimates are not commitments, estimate with accuracy over precision, and use relative sizes when estimating. I'll breifly explain each. Estimate as a team: the people who do the dev work, the development team, estimate the PBIs in the presence of the product owner (there for clarification) and the scrum master (there to guide the process). Estimates are not commitments: Enforcing estimates as commitments would mean artificially inflating the size of the dev team's estimates; the only way to get honesty from the dev team is to allow some leeway for estimation in error. Estimate with high accuracy/low precision: this is common sense...estimating with high precision is likely to cause unneccessary effort and bad estimates; whereas, estimating with low precision allows a roughly right estimate. Use relative sizes when estimating: Plain and simple, it's much harder to size up things in absolute terms versus relative terms (for humans); let humans do what they're good at.
question
What are the two metrics used (by most teams) to estimate the size of a PBI?
answer
Story points and ideal days. These can easily be explained by analogy. Story points is akin to saying "relative development effort points" or "relative dev time points", and it takes into account the physical size of the finished product along with the complexity of developing it; these "points" are relative to the points associated to other PBIs. Ideal days, on the other hand, is used like quarters of a football game. A football game is played in 1 ideal hour, but 3-4 real hours, because of timeouts, interruptions, etc. Ideal days work in much the same way: what takes 1 ideal day (8 man-hours of focused, uninterrupted development) might be 3 real days for a development team.
question
What is planning poker?
answer
Planning poker is a way of coming up with PBI estimates, while motivating a lively discussion by team members to expose assumptions/misunderstandings about a PBI and come up with a consensus of how a PBI should be sized up.
question
What is the estimation domain (of numbers) of a PBI?
answer
Rather than a continuous (e.g. 1-100) range, typically a set of a like-fibonacci sequance is used (½, 1, 2, 3, 5, 8, 13, 20, 40, 100..) or a set of powers of two (1, 2, 4, 8, ..). The point of doing this is to emphasize accuracy of rel size estimates over precision.
question
How does one play the game of planning poker?
answer
Planning poker is played by giving all development team members cards with numbers from the domain mentioned above, as well as a "?" card and a special card. A product owner reads a PBI and the team then clarifies the PBI reqs with the product owner. Once this is done, all members estimate the weight of the PBI using a card and expose the card to other members at the same time. If there is consensus, we stop, else a discussion is held and the process is repeated (showing cards) until consensus is reached. Note, a consensus must be reached on a number within the deck...there is no average or in between. The "?" card is a request for clarification or statement of incompetency in this area and the special card signals "I'm done; I want a break/food!".
question
What is velocity? what is its purpose?
answer
Velocity is a measure of how much a scrum team accomplishes over time. It's measured in dividing story points or ideal days per sprint. (note: only fully accomplished PBIs count) The purpose of velocity is twofold: [1] a metric useful for planning what the team can realistically get done [2] an metric for internal team improvement.
question
How and why should we calculate a velocity range?
answer
A velocity range can be easily calculated by taking 90% confidence intervals of the teams velocity low and velocity high, and using this range for calculations. Using a range as opposed to an average is superior, because it favors accuracy and reduces precision (which is artificial because more precise is more prone to error).
question
What is forecasting velocity and when is it needed?
answer
Forecasting velocity occurs when a team has never worked together before. In this case, it is necessary to forecast the velocity of the team by having them plan a sprint (ideally 2 sprints) and using these as a high and low to calculate a forecasted velocity range for the team. Of course, once a sprint happens, throw out the forecast and use the experimental data.
question
How is velocity affected over time?
answer
Velocity improves over time for a good scrum team, as they are constantly improving, to a point. At this point, a plateau has been hit, and bigger changes may need to be made to keep improving velocity (newer tools, training, environment, staff, etc). These changes are usually met with slight dip in productivity followed by an increase.
question
Why is it a bad idea to reward separate teams based on velocity?
answer
This will likely just cause a team to get smart and "inflate" its point system so that they just increase the relative values of what each PBI becomes in terms of points.
question
What is technical debt and what are the 3 main types of this debt?
answer
Technical debt has evolved to generically refer to any shortcuts taken or bad practices that exist within a software system. The 3 main categories of this debt are naive debt, unavoidable debt, and strategic debt. Naive debt refers to bad design, implementation or business decisions which occur due to bad practices, training, etc. and could be avoided with appropriate training, smart decisions, etc. Unavoidable debt is debt which may be predictable but is unavoidable by virtue of the way things are; an example is using a 3rd party component in an application means that eventually we will have to modify our app when the 3rd party component changes (this is highly predictable, but unavoidable). Finally, strategic debt is technical debt we take on for a reason of economics/business. One example is if a self-funded company is running out of money, it may be best to get a slightly-flawed product out to the market early and gain money to further development.
question
List and explain a few consequences of technical debt.
answer
An unpredictable tipping point for the product, product atrophy, increased development costs, and universal frustruation. Unpredictable tipping point: Essentially, the tipping point of a product is the point in time when any change to the product causes chaos; with increasing technical debt, the chances of reaching this point increase, and it's hard to revert back once this point is reached. Product atrophy - Because tech debt is high, it's hard for the development to fix bugs and implement new features. This causes the product to atrophy and become known as "old" in the market. Increased development costs - When technical debt is high, even seemingly simple changes become hard to implement and take a lot more time (therefore cost a lot more). Universal frustruation - The customer becomes frustruated with the product (therefore the business team), the business team becomes frustruated with the dev team, the dev team becomes frustruated trying to work out of debt.
question
What are the causes of strategic and naive tech debt?
answer
Strategic and naive debt are the product mainly of the effects of pressuring a team to meet a deadline by falsely accelerating velocity. Presuring a team to meet a deadline off pace the actual projected deadline (determined with the actual velocity) causes a team to deliberately cut corners to meet deadlines. This "falsely accelerates" the velocity of the team. In future releases and sprints, the team has to build atop an already debt-ridden product, further increasing the need to falsely accelerate velocity, and the cycle continues.
question
How do we manage tech debt?
answer
To manage tech debt, a balanced business/tech discussion must be held. There are three ways to effectively manage technical debt throughout the development process. [1] Manage the accrual of this debt [2] make the debt visible when it exists [3] repay the debt (service the product)
question
How can we manage the accrual of tech debt?
answer
The first step is to use strong technical feedback, such as test-driven development, continuous integration, simple design, etc. Next, we can use a strong definition of done to help ensure that we are very confident that the software we develop works well and is bug-free and well-formatted, styled, etc. Finally, we can truly understand the economics of technical debt in order to truly weight the decision to rush development for a release. Releasing a product early will likely present an immediate economic win over taking the time to stop technical debt; however, if the team is not diligent about paying back its debt, the short-term win may not stay for the long-term.
question
How can we make technical debt visible to both technical and business people?
answer
For business people, we can make technical debt visible by, say, tracking the velocity over time of the scrum team. As velocity slows, if we assume it is largely due to technical debt, we can see the ramifications of the technical debt by calculating the cost of development at the slower velocity compared to the normal velocity. Aditionally, to make the technical debt visible at the technical level, we may [1] use existing defect tracking software [2] add technical debt entries to the product backlog or [3] keep a tech debt backlog in plain site, next to the product backlog board, so that technical debt is visible during sprint planning.
question
How do we service our technical debt?
answer
[1] Decide if we want to repay the technical debt. [2] Repay debt as-it's-found to a reasonable time threshold [3] Every sprint, consider designating a certain amount of time to eliminating some known high-interest technical debt, in the areas in which we're already working.
question
What other rules should we follow while servicing technical debt?
answer
Don't service all technical debt: if the product is near the end of lifespan, has a very short lifespan, or is a throwaway prototype it doesn't make much economic sense to invest in eliminating technical debt. Use the boyscout rule to a certain threshold: clean up the development environment (i.e. bad practices, etc.). Repay debt incrementally (not all-in-one sprint), repay debt in areas in which we're giving new value, and repay high-interest debt first (e.g. components which are frequently used and have a lot of dependencies).
question
What does the product owner do?
answer
He is both a business analyst and a product tester, ensuring that high-level tests for products are passed (e.g. should work in all major browsers, plus IE 8 & 9).
question
What responsibilities does the product owner have?
answer
Manage economics: PB level (re-prioritize PBIs in light of new information) sprint level (make sure each sprint returns good features for the money) release level (make business decisions regarding when to do a release, if future sprints will continue, how a release should change in light of new info) Planning: plan at the portfolio-, product-, release-, and sprint- level with others (stakeholders, dev. team) on what to build, etc. Grooming: ensure that grooming is done smoothly, delegate work where needed (e.g. size estimation to dev team), and maintain a good PB Define Acceptance Criteria//make sure they're met: Acceptance criteria which need be met for a PBI to be "done" are defined (and possibly tests developed), and the Powner may run tests himself Constant collaboration: A Powner should constantly be collaborating with the dev team (answering questions, etc.) to ensure a good feature is being pushed out within each sprint. Get Input from stakeholders: The Powner is the sole voice of the entire stakeholder community, internal and external. He thus gathers input from all stakeholders (or delegates some of this) and synthesizes a vision for developing features.
question
What kind of characteristics need a product owner have?
answer
She needs domain skills (being a visionary for the product, knows not everything can be anticipated up-front, and has business and domain expertise). She needs people skills (good relationship & comm. with stakeholders, good at gathering consensus, powerful motivator). She needs decision making ability (is empowered to make decisions, willing to make hard decisions, decisivie, and balances economic and technical needs). She needs accountability (accepts responsiblity for the product, committed and available, and acts like a scrum team member).
question
Who is the Powner?
answer
It varies: where/for whom is the product being developed need be assessed. If internally developed product, Powner is an empowered person from group receiving the benefit. If commercial development, Powner is an empowered person inside the op (in the compnay) who acts as a voice for customers/users. If outsourced dev, the Powner is a rep from the company paying/receiving value. If component team, the Powner is technical person who can balance the PB.
question
How/when are multiple Powners appropriate?
answer
Multiple Powners are appropriate when either (a) the commitments are too many for one person (a team is afforded the Powner, but Powner is ultimate authority), (b) the Power spends a lot of time away from the dev team (at meetings, etc), so there is a Powner proxy who makes decisions when Powner is gone, but is not real Powner (or ultimate source of auth), (c ) there are many, many people in the dev effort (10s to 100s to 1000s). Powner hierarchy may be setup, but there are mutliple lines of Powners overseeing multiple individual teams, leading up to a chief Powner.
question
What are the roles of the scrum master?
answer
The scrum master is a... coach - help the Powner and dev team use scrum effectively, and get the Powner to get the most business value from scrum servant leader - The scrum master leads the team by serving the team in making them more effective process authority - sm is an authority on the scrum process the team uses. She is the person who makes sure work is getting done in an efficient way Interference shield - sm is responsible for keeping dev team delivering value and questioning/blocking interference from other sources (managers, other teams, etc.) remove impediments which block the dev team (and the dev team can't remove themselves) scrum helps change minds and answer questions where people are hesitant to make scrum-like changes
question
What characteristics/skills should a good sm have?
answer
This is a good starter list: knowledgeable (about scrum) questioning (why practices are done) patient (asking probing questions rather than providing answers) collaborative (able to work with Powner, dev team, and other parties as necessry) protective (of the team, making sure that all members are and stay comitted) transparent communication (without a hidden agenda)
question
Who should be a sm?
answer
A scrummaster is someone who comes from usually a somewhat technical (e.g. development, testing, etc.) background and has the time to perform scrum-master roles (as opposed to those who should be leveraging tech expertise most of the time). A SM is usually not a full time role, and it can usually be performed with other roles (e.g. scrum master of multiple teams, scrum master and tester, etc.)
