Scrum Key Words

Question 0

Burndown charts

Answer 0

Burndown charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward.

Question 1

Daily Scrum Meeting

Answer 1

A fifteen-minute daily meeting for each team member to answer three questions:

1. “What have I done since the last Scrum meeting? (i.e. yesterday)”
2. “What will I do before the next Scrum meeting? (i.e. today)”
3. “What prevents me from performing my work as efficiently as possible?”

Question 2

Impediment backlog

Answer 2

A visible list of impediments in a priority order according to how serious they are blocking the team from productivity.

Question 3

What is Roman vote

Answer 3

Thumb vote

Question 4

Impediments

Answer 4

Anything that prevents a team member from performing work as efficiently as possible is an impediment. The ScrumMaster is charged with ensuring impediments get resolved. ScrumMasters often arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting.

Question 5

The product backlog

Answer 5

The product backlog (or “backlog”) is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, it is the sole responsibility of the product owner to prioritize the product backlog.

Question 6

Product backlog item

Answer 6

In Scrum, a product backlog item (“PBI”, “backlog item”, or “item”) is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog items are decomposed into one or more tasks.

Question 7

Product burndown chart

Answer 7

In Scrum, the product burndown chart is a “big picture” view of a project’s progress. It shows how much work was left to do at the beginning of each sprint. The scope of this chart spans releases; however, a release burndown chart is limited to a single release.

Question 8

What is the product owner?

Answer 8

In Scrum, a single person must have final authority representing the customer’s interest in backlog prioritization and requirements questions.

This person must be available to the team at any time, but especially during the sprint planning meeting and the sprint review meeting.

Question 9

Challenges of being a product owner:

Answer 9

1. Resisting the temptation to “manage” the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself.
2. Not to add more important work after a Sprint is already in progress.
3. make hard choices during the sprint planning meeting.
4. Balancing the interests of competing stakeholders.

Question 10

What is the release?

Answer 10

The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it.

Question 11

What is released burn down chart?

Answer 11

In Scrum, the release burndown chart is a “big picture” view of a release’s progress. It shows how much work was left to do at the beginning of each sprint comprising a single release.

Question 12

What is a scrum master?

Answer 12

The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster works to assist both the team and product owner in the following ways:

Question 13

Task of the scrum master

Answer 13

· Remove the barriers between the development and the product owner so that the product owner directly drives development.

· Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.

· Improve the lives of the development team by facilitating creativity and empowerment.

· Improve the productivity of the development team in any way possible.

· Improve the engineering practices and tools so that each increment of functionality is potentially shippable.

· Keep information about the team’s progress up to date and visible to all parties.

Source: Agile Project Management with Scrum, K

Question 14

Sprint

Answer 14

An iteration of work during which an increment of product functionality is implemented. By the book, an iteration lasts 2 weeks to 30 days.

Question 15

Sprint backlog

Answer 15

Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint’s goals, and selected set of product backlog items.

Question 16

Sprint goals

Answer 16

Sprint goals are the result of a negotiation between the product owner and the development team.

Question 17

Sprint planning meeting

Answer 17

The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint.

The product owner and all team members agree on a set of sprint goals, which is used to determine which product backlog items to commit from the uncommitted backlog to the sprint. Often new backlog items are defined during the meeting. This portion of the sprint planning meeting is time-boxed to four hours.

Typically the team will then excuse the product owner from the room and break the backlog Items down into tasks. The product owner is expected to be on call during this phase for renegotiation or to answer questions that affect the time estimates. This portion of the sprint planning meeting is time-boxed to four hours. Sometimes teams insert placeholder tasks (with rough estimates) for the product backlog items they don’t expect to start working until later in the sprint.

Question 18

Sprint Retrospective Meeting

Answer 18

The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting.

The sprint retrospective should be time-boxed to three hours. ( pay close attention to this meeting)

Question 19

Sprint task

Answer 19

In Scrum, a sprint task (or task) is a unit of work generally between four and sixteen hours. Team members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the sprint burndown chart. Tasks are contained by backlog items.

Scrum literature encourages splitting a task into several if the estimate exceeds twelve hours.

Question 20

A team (or “Scrum team”)

Answer 20

is optimally comprised of seven plus or minus two people.

For software development projects, the team members are usually a mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. This is often called “cross-functional project teams”. Agile practices also encourage cross-functional team members.

Question 21

Team Member

Answer 21

In Scrum parlance, a team member is defined as anyone working on sprint tasks toward the sprint goal.

Question 22

Velocity

Answer 22

In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.

Once established, velocity can be used to plan projects and forecast release and product completion dates.

Question 23

What are the 3 Artifacts?

Answer 23

Burndown charts
Product backlog
Sprint backlog

Question 24

What are the four ceremonies?

Answer 24

Daily Standup Meeting Sprint Planning Meeting Sprint Review Retrospective

Question 25

Did you use automated test tools on your projects? Explain how that worked.

Answer 25

At the end of each iteration you want to have something that your customer/client can "see." Automated testing allows quick identification and isolation of development defects as well as the ability to test development work completed in previous iterations.

Question 26

Have you used story cards or use cases? Explain how that worked for the team.

Answer 26

Often, Agile projects are associated with the use of story cards. However, our goal is to simply understand if our potential team member is comfortable implementing a project (designing, developing, testing, etc) with business information which has been documented in some way. The requirements (story cards or use cases or a combination of both) should have enough information to provide guidelines for developing and testing and also allow the development team to come up with a creative and effective solution. By asking this question, you want to understand if your potential team member is comfortable working with requirements in a structured development environment (versus brief summaries from which the developers build code). Again, this is a matter of matching the Agile candidate’s experience with your organization’s needs.

Question 27

How comfortable are you with ever-changing requirements?

Answer 27

Many development methodologies specify that requirements are locked down at the beginning of a project. Although that is not the case in Agile, it does not mean that requirements are loosey-goosey! The advantage of Agile and its short iterations is that it is easy to quickly recognize that work is not progressing as desired – that what the customer ‘asked for’ is not what they ‘wanted’ – and the requirements must be changed. Team members should be able to handle such changes on an Agile project. It shouldn’t be so tied to code, a story card or any other component of work that prevents providing a solution which meets the customer’s needs. The general idea is that requirements can change a lot at the beginning of the release, and very little at the end.

Question 28

Did people play multiple roles on your development team?

Answer 28

Here we get back to multidisciplinary teams. What you are really trying to understand from this question is how well an individual would fit into your organization and your style of Agile development. If your organization is one in which individuals select a specialized role (such as Java Developer) as part of their career path, your interview candidate may have difficulty on your team if she is more comfortable working in Agile projects where she has had the ability to play multiple roles (Scrum for example). Conversely, if your candidate’s primary experience was developed on projects where roles were clearly defined and individuals did not work in multiple capacities, then he may be uncomfortable in an organization where team members can play any role on a project to achieve its end goal. You must choose the candidate which fits your organization well and is flexible enough to suit the needs of your Agile project implementation. Two particular roles that are more easily interchanged are business analysts and testers, other roles are harder to be "multifunctional."

Question 29

What project management tools were used on your project?

Answer 29

This question is more for Agile project managers. Do you have corporate PM tool standards? If so, this question becomes quite important. Agile has a new breed of PM tools including Rally Software, Version One and XPlanner. These tools bear no resemblance to the waterfall PM tools like MS-Project or Clarity. If your candidate is more comfortable using one of these Agile PM tools, try to identify if they will be able to fit their Agile project plans (and issues, milestones, change requests, etc.) into your company’s structure.

Question 30

Can you explain the purpose of a burndown chart?

Answer 30

This is more of a question for candidate project managers, although all Agile people should know the answer. A burndown chart is a graph that shows the progress of the team in terms of work "burned through." The work is usually put in terms of a set of "story points" which represent functionality. Once a piece of functionality is coded and tested and reviewed by the user, it is considered to be "burned" and the graph will reflect this. The graph should show a steady movement down until it is clear that the team will have completed the story point backlog by the release date. There is also a variation called a "burnup chart" that works the same way but can handle scope changes more easily than the burndown variety. Again, you want to see how the candidate will link their burndown/burnup chart into your overall project management structure.

Question 31

What does project velocity mean?

Answer 31

This is a PM question, but most Agile people should know the answer. Project velocity is the rate at which a team is "burning" through story points, so a possible velocity might be "30 story points per iteration." That means that so far, the team has been able to identify, code and test 30 units of functionality (story points) in an average iteration and can expect to do about that much in future iterations, giving a fairly good view towards what can be accomplished by a release date. Hopefully, these twelve questions can be a good start for your qualification process in bringing in new Agile consultants or candidate employees. Our hope is that you can build a highly-qualified team that will fit in well with your corporate development process, culture and PM standards.

Question 32

Epic

Answer 32

A very large user story broken up into smaller stories.

Question 33

Spike

Answer 33

A short, time-boxed piece of research, usually technical, on a single story that is intended to provide just that is intended.

Question 34

Story points

Answer 34

A unit of measurement applied to the size of the story.

Question 35

Vision statement

Answer 35

A high level description of a product which includes who it is for, why it is necessary and what differentiates it from similar products.

Question 36

XP Practices

Answer 36

The set of development practices,including pair-programming, test-first, or test-driven development (TDD) and continuous refactoring,which are drawn from the XP methodology.

Question 37

Have you ever tracked velocity? How would you determine a teams Sprint velocity?

Answer 37

Check the burn down chart.

Question 38

How is my Product Owner doing?

Answer 38

Is the Product Backlog prioritized according to his/her latest thinking? __ Are all the requirements and desirements from all stakeholders for the product captured in the backlog? Remember the backlog is emergent. __ Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more granular towards the top, with general epics at the bottom. It's counterproductive to overanalyze too far past the top of the Product Backlog. Your requirements will change in an ongoing conversation between the developing product and the stakeholders/customers. __ Could any requirements (especially those near the top of the Product Backlog) be better expressed as independent, negotiable, valuable, estimable, small, and testable user stories? __ Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle may be adding automated test and refactoring to the definition of "done" for each backlog item. __ Is the backlog an information radiator, clearly visible to all stakeholders? __ If you're using an automated tool for backlog management, is it actually working for you? Automated management tools introduce the danger of becoming information refrigerators without active radiation from the ScrumMaster. __ Can you help radiate by showing everyone printouts? __ Can you help radiate by creating big visible charts? __ Have you helped your Product Owner organize backlog items into appropriate releases (e.g., front burner, back burner, fridge)? __ Do all stakeholders (including the team) know whether the release plan still matches reality, based on the current velocity (e.g., story points per Sprint)? __ Did your Product Owner adjust the release plan after the last Sprint Review Meeting? The minority of Product Owners who ship adequately tested products on time replan the release every Sprint, usually deferring some work for future releases as more important work is discovered. You might try showing everyone the Mike Cohn-style Product/Release Burndown Charts after the items have been acknowledged as “done” during every Sprint Review Meeting. This allows early discovery of scope/schedule drift. - See more at: https://www.scrumalliance.org/community/articles/2010/november/an-example-scrummaster-s-checklist#sthash.ATdtqw6g.dpuf

Question 39

How is my team doing?

Answer 39

__ Are team members spending most of their time in the state of flow? Some characteristics of this state (from Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi): Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one's skill set and abilities); Concentrating and focusing, a high degree of concentration on a limited field of attention; A loss of the feeling of self-consciousness, the merging of action and awareness; Distorted sense of time - one's subjective experience of time is altered; Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed); Balance between ability level and challenge (the activity is neither too easy nor too difficult); A sense of personal control over the situation or activity; The activity is intrinsically rewarding, so there is an effortlessness of action. __ Do team members seem to like each other, goof off together, and celebrate each other's success? __ Do team members hold each other accountable to high standards, and challenge each other to grow? __ Are there issues/opportunities the team isn't discussing because they're too uncomfortable? See Crucial Conversations: Tools for Talking When Stakes are High. Or consider enlisting a professional facilitator who can make uncomfortable conversations more comfortable. __ Have you tried a variety of formats and locations for Sprint Retrospective Meetings? See Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen) for some ideas. __ Has the team kept focus on acceptance criteria? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the product backlog items committed for this Sprint. __ Does the Sprint Backlog reflect what the team is actually doing? Interruptions and distractions that don't contribute to Sprint goals are impediments. __ Are your team's task estimates and/or your taskboard up to date? __ Are the team self-management artifacts (taskboard, Sprint Burndown Chart, etc.) visible to the team, convenient for the team to use? __ Are the team self-management artifacts adequately protected from micromanagers? __ Do team members volunteer for tasks? __ Are technical debt repayment items (to address issues sapping your team's velocity) captured in the backlog, or otherwise communicated with the Product Owner? __ Are team members leaving their job titles outside the team room? __ Does the entire team consider itself collectively responsible for testing, user documentation, etc.? - See more at: https://www.scrumalliance.org/community/articles/2010/november/an-example-scrummaster-s-checklist#sthash.ATdtqw6g.dpuf

Question 40

How are our engineering practices doing?

Answer 40

__ Does your system in development have a "push to test" button so that anyone (same team or different team) can conveniently detect when they've broken it? Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.). __ Do you have an appropriate balance between automated end-to-end system tests (a.k.a. "functional tests") and automated unit tests? __ Is the team writing both system "functional" tests and unit tests in the same language as the system they're developing (rather than using proprietary scripting languages or capture playback tools only a subset of the team knows how to maintain)? It's possible. __ Has your team discovered the useful gray area between system tests and unit tests? __ Does a continuous integration server automatically sound an alarm within an hour (or minutes) of someone causing a regression failure? ("Daily builds are for wimps." -- Kent Beck) __ Do all tests roll up into the continuous integration server result? __ Have team members discovered the joy of continuous design and merciless refactoring, as an alternative to Big Design Up Front? Refactoring has a strict definition: changing the internal structure of a system without changing its external behavior. Refactoring should occur several times per hour, whenever there is duplicate code, complex conditional logic (visible by excess indenting or long methods), poorly named identifiers, excessive coupling between objects, excess responsibility in one object, etc. Refactoring with confidence is practical with automated test coverage. Holes in test coverage and deferred refactoring are cancers called technical debt. __ Does your definition of "done" for each functional Product Backlog Item include full automated test coverage and refactoring? You╩╝re unlikely to build a potentially-shippable products every Sprint without learning eXtreme Programming practices (as described by Kent Beck, Ron Jeffries, etc.). __ Are team members pair programming most of the time? Pair programming can dramatically improve code maintainability and reduces bug rates. But it challenges people's boundaries and sometimes seems to take longer (if we put quantity over quality). Rather than force people to do this, lead by example by initiating paired workdays with team members. Some of them will start to prefer working this way. - See more at: https://www.scrumalliance.org/community/articles/2010/november/an-example-scrummaster-s-checklist#sthash.ATdtqw6g.dpuf

Question 41

How is the organization doing?

Answer 41

__ Is the appropriate amount of inter-team coordination happening? Scrum of Scrums is only one way to achieve this. Also consider sending ambassadors to other teams' standups. __ Is the inter-team coordination done by the people with their hands dirty in the work, as recommended? __ Are your ScrumMasters meeting with each other, working the organizational impediments list? __ When appropriate, are the organizational impediments pasted to the wall of the development director's office? Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? (But remember Ken Schwaber's discovery: "A dead ScrumMaster is a useless ScrumMaster.") __ Is your organization one of the few with career paths compatible with the collective goals of your teams? Answer "no" if there's a career incentive to do programming or architecture work at the expense of testing, test automation, or user documentation. __ Are you helping to create a learning organization? __ Has your organization been recognized by the trade press or other independent sources as one of the best places to work or a leader in your industry? - See more at: https://www.scrumalliance.org/community/articles/2010/november/an-example-scrummaster-s-checklist#sthash.ATdtqw6g.dpuf