Sprint Team

7/27/2019 Sprint Team

1/39

Table of contents

Contents1 Are scum masters part of performance appraisal ..................................................................................... 5

2 Is it possible to shuffle team in between a sprint? .................................................................................... 6

3 What to do if a team member misses a sprint planning? .......................................................................... 7

4 What happens between sprints? ............................................................................................................... 8

5 What to do when a sprint is finished early? .............................................................................................. 9

6 Handling unexpected features during sprint ........................................................................................... 10

7 Sprint item takes longer then expected to be completed. What should we do? .................................... 11

8 What should a proper Ready for Sprint definition contain? .................................................................... 12

9 Product Owner introduces ungroomed (unfamiliar, not estimated) User Story(s) into the Sprint

Planning meeting ........................................................................................................................................ 13

10 What to do with unfinished stories and tasks in SCRUM sprint? .......................................................... 14

11 Confused about modifying the sprint backlog during a sprint .............................................................. 15

12 What should I do if one of my Team-Members is Ill or in Holidays. ...................................................... 16

13. How long were the iterations (or sprints) on the projects you worked on? ........................................ 16

14. Are you a Certified Scrum Master (CSM)? If so, how do you view the way Scrum projects need to be

organized? ................................................................................................................................................... 16

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

16. Have you done continuous integration on a project before? Describe. ............................................... 17

17. Did your iterations overlap? For instance, were the testers still testing Iteration 6 while Iteration 5

was being designed/developed? ................................................................................................................ 17

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

19. How did you manage traceability of the requirements to testing?...................................................... 18

20. How comfortable are you with ever-changing requirements? ............................................................ 18

21. Did people play multiple roles on your development team? ............................................................... 18

22. What project management tools were used on your project? ............................................................ 18

23. Can you explain the purpose of a burndown chart? ............................................................................ 19

24. What does project velocity mean? ....................................................................................................... 19

25 ................................................................................................................................................................ 19

26 ................................................................................................................................................................ 19

27 ................................................................................................................................................................ 19

28 ................................................................................................................................................................ 20


2/39

29 ................................................................................................................................................................ 20

30 ................................................................................................................................................................ 20

31 ................................................................................................................................................................ 20

32 ................................................................................................................................................................ 21

33 ................................................................................................................................................................ 21

34 ................................................................................................................................................................ 21

35 ................................................................................................................................................................ 21

36 ................................................................................................................................................................ 21

37 ................................................................................................................................................................ 21

38 ................................................................................................................................................................ 21

39 ................................................................................................................................................................ 22

40 ................................................................................................................................................................ 22

41 ................................................................................................................................................................ 22

42 ................................................................................................................................................................ 22

43 ................................................................................................................................................................ 22

44 ................................................................................................................................................................ 23

45 ................................................................................................................................................................ 23

46 ................................................................................................................................................................ 23

47 ................................................................................................................................................................ 23

48 ................................................................................................................................................................ 23

49 ................................................................................................................................................................ 23

50 ................................................................................................................................................................ 24

51 ................................................................................................................................................................ 24

52 ................................................................................................................................................................ 24

53 ................................................................................................................................................................ 24

54 ................................................................................................................................................................ 24

55 ................................................................................................................................................................ 24

56 ................................................................................................................................................................ 24

57 ................................................................................................................................................................ 24

58 ................................................................................................................................................................ 24

59 ................................................................................................................................................................ 24

60. What is a Moscow list? ......................................................................................................................... 25

61. What is a Sprint ? .................................................................................................................................. 25


3/39

62. What is a Test stub ? ............................................................................................................................. 25

63. What is a Test-Driven Development (TDD) ? ........................................................................................ 25

64. What is a story board ? ......................................................................................................................... 25

65. What is a Release candidate ? .............................................................................................................. 25

66. What is Re-factoring ? ........................................................................................................................... 25

67. What is an epic ? ................................................................................................................................... 26

68. What is functional test ? ....................................................................................................................... 26

69. What is a business facing test ? ............................................................................................................ 26

70. What is a use case ? .............................................................................................................................. 26

71. What is UML ? ....................................................................................................................................... 26

72. What is a boundary testing ? ................................................................................................................ 26

73: What are the benefits of Agile Software development? ...................................................................... 26

74: What is a Sprint ? ................................................................................................................................. 26

75: What is a Test stub ? ............................................................................................................................ 26

76: What is a Test-Driven Development (TDD) ? ....................................................................................... 27

77: What is a story board ? ........................................................................................................................ 27

78: What is a Release candidate ? ............................................................................................................. 27

79: What is Re-factoring ? .......................................................................................................................... 27

80: What is an epic ? .................................................................................................................................. 27

81: What is the Agile manifesto? ............................................................................................................... 27

82: In what does the agile testing(development) methodology differs from the other testing

(development) methodologies? ................................................................................................................. 27

83: Can agile methodology be applied also in other than software testing and development projects?. 27

84: Are you able to name five main characteristics of agile methodology from your point of view? ...... 28

85: Describe a case where you personally used the agile methodology (or was a part of a team which

used it). ....................................................................................................................................................... 28

86: What are some of the key features of agile development? ................................................................ 28

87: How do you know that you are using agile development? ................................................................. 28

88: In agile practice, what does the daily stand up meetings entail? ........................................................ 28

Scrum Master Interview Questions........................................................................................................ 30

ExperienceAgile specific .......................................................................................................................... 30

Exercises ...................................................................................................................................................... 31

Mock Demonstrations................................................................................................................................. 31

ScrumMaster Interview TipsRead later................................................................................................ 32


4/39

What are the major responsibilities of a Scrum master? ........................................................................... 34

Team Back into Flow ................................................................................................................................... 36


5/39

1 Are scum masters part of performance appraisal

ScrumMasters are in service to the team; they don't manage the team. Creating a higher status position

(evaluator) is an impediment to the team's self-organization

-- and to the team members learning how to give each other feedback and manage their ownperformance.

By all means, coach people as they learn new skills. Help the team learn to self-organize by holding up a

mirror to their processes, and challenge them to think and decide on their own.

The ScrumMaster and team members know how each other are performing. When the ScrumMaster

and the team are committed to giving each other congruent feedback, there's no need for a

performance evaluation:

People know how they are doing and are working to improve every day.

Planning is about doing commitment and about splitting committed user stories to tasks.

have a planning session with him after he is back.

Definitely no. Planning session after he is back doesn't make sense because commitment had to be

already done.

have a planning session with him before he goes on annual leave i.e. before sprint planning.

Definitely no. There should be no planning when current sprint is not completed = result of current

sprint is unknown and nobody knows if all user stories will be completed and customer will be satisfied

with them on review.

don't schedule him for any task and assign him on non sprint tasks e.g. spikes etc

Definitely no. He will be back and his capacity should be used for sprint target.

---->have his peers plan on his behalf during sprint planning and absent person can then add tasks when

he is back and if he cannot do all the work he can descope.

--->This is correct. The team does commitment - not particular team member.

Team commits to set of user stories because they know their velocity and based on their professional

guess they can modify commitment for the next sprint based on available capacity. There should be no

tasks assigned to single developer upfront. Developers should be cross functional even it is not always

possible, they should still be able to at least split user story to tasks. There can be problem with

estimating tasks but in my opinion it is not needed at all.

have him sit with another developer and do pair programming for a while.

Definitely no. Pair programming should be covered by velocity itself. If you don't count with developer it

is same like saying that he will be away whole sprint. Why should customer pay time of developer who

did nothing during the sprint?


6/39

2Is it possible to shuffle team in between a sprint?

Is it possible to shuffle sprint team members in between a sprint?

Of course it is possible!! You should never be so subservient to a methodology that you allow it to

stop you doing things that you know that you need to do.

What are the potential drawbacks of doing this?

The obvious drawback is that the people who are moved around end up working on a different part

of the problem. They may need to acquire the domain and technology-base knowledge they didn't

need to have before the shuffle. They will definitely need to acquire understanding of parts of the

codebase that they didn't previously. These overheads will tend to make reduce "agility" ... in the

normal sense of that word.

But if there is an overwhelming reason to shuffle the team, you may just have to wear that

(hypothetical) loss of efficiency / agility. If you have people who can't cope with certain tasks, or

can't work together, a well executed shuffle could get back that lost efficiency ... and some more.

One of the core concepts of Scrum Agile istimeboxingand that means basically a fixed period of

time for what I call focused activity. This focused activity would at it's base be the sprint you are in.

Given that, I always found the biggest drawback is a loss of focus when changing sprint team

members during a sprint. The loss of focus means a loss of work and team velocity. The only times I

have done this where it worked was because of a particularly bad team member or an emergency

situation where a team member was out sick but the work they were on that sprint was higher

priority than other teams.

What is more interesting as a question is to ask "why" you are considering moving team members

around. Usually this is an indicator of a bigger problem and, as you mentioned, a situation as risen.If you must move team members around note the loss of focus which also means a loss of work and

try to solve for the problem that came up initially to prevent it from happening again.
http://programmers.stackexchange.com/questions/198862/is-it-possible-to-shuffle-team-in-between-a-sprinthttp://programmers.stackexchange.com/questions/198862/is-it-possible-to-shuffle-team-in-between-a-sprinthttp://en.wikipedia.org/wiki/Timeboxinghttp://en.wikipedia.org/wiki/Timeboxinghttp://en.wikipedia.org/wiki/Timeboxinghttp://en.wikipedia.org/wiki/Timeboxinghttp://programmers.stackexchange.com/questions/198862/is-it-possible-to-shuffle-team-in-between-a-sprint


7/39

3What to do if a team member misses a sprint planning?

Planning is about doing commitment and about splitting committed user stories to tasks.

have a planning session with him after he is back.

Definitely no. Planning session after he is back doesn't make sense because commitment had to be

already done.

have a planning session with him before he goes on annual leave i.e. before sprint planning.

Definitely no. There should be no planning when current sprint is not completed = result of current

sprint is unknown and nobody knows if all user stories will be completed and customer will be

satisfied with them on review.

don't schedule him for any task and assign him on non sprint tasks e.g. spikes etc

Definitely no. He will be back and his capacity should be used for sprint target.

have his peers plan on his behalf during sprint planning and absent person can then add tasks when

he is back and if he cannot do all the work he can descope.

This is correct. The team does commitment - not particular team member. Team commits to set of

user stories because they know their velocity and based on their professional guess they can modify

commitment for the next sprint based on available capacity. There should be no tasks assigned to

single developer upfront. Developers should be cross functional even it is not always possible, they

should still be able to at least split user story to tasks. There can be problem with estimating tasks

but in my opinion it is not needed at all.

have him sit with another developer and do pair programming for a while.

Definitely no. Pair programming should be covered by velocity itself. If you don't count with

developer it is same like saying that he will be away whole sprint. Why should customer pay time of

developer who did nothing during the sprint?\
http://programmers.stackexchange.com/questions/94540/what-to-do-if-a-team-member-misses-a-sprint-planninghttp://programmers.stackexchange.com/questions/94540/what-to-do-if-a-team-member-misses-a-sprint-planninghttp://programmers.stackexchange.com/questions/94540/what-to-do-if-a-team-member-misses-a-sprint-planning


8/39

4What happens between sprints?

I'm working on a project loosely following the scrum model.

To make it clear: Your managers probably told you about Scrum but what you perform is not Scrum.

How long does this typically take?

Sprint review meeting + Sprint retrospective meeting ends current sprint. In short sprints they

should take something between 30 minutes - 1 hour together. Next working day starts a new sprint

by performing Sprint planning meeting 1 and 2. Based on the team size and sprint length these

meeting can takes 2 - 4 hours.

Should the whole team be involved?

Whole team must be involved in meetings mentioned in previous answer.

Does it strictly have to finish before developers start working on the next sprint items?

Yes because until review meeting is done you don't know if customer accepts result of previous

sprint and you don't know what users stories will be committed in planning meetings.

Is this when code review and testing take place?

No. Code review and testing is part of sprint. Developers must do everything needed to deliver

working code satisfying requirements. This can include code reviews and it always must include

some sort of automated tests validating that code works and does what it is supposed to do

otherwise the user story cannot be considered as done.

The main mental shift is with QA. Many developers think that QA is there to validate that code works

and does what it is supposed to do. Definitely no. That is developer job.

QA should participate on product development. Their main responsibility in sprint should be

communication with product owner and creation of automated acceptance tests for acceptance

criteria (definition of done) which will validate that user story is really done and the application

passes all new requirements. In small teams this can be responsibility of developers as well.

QA should also do some manual testing to keep product consistent and to discover missing features,

validate user experience with UI, etc. QA is not there to hunt for bugs and regression testing -

regression testing should be highly automated.

In my experience this is where most companies moving to agile fails.

From my experience, there is no time between sprints, other than the weekend. Towards the middle

of the sprint, the teams that I've been a member of work with the product owner to do some story

grooming or preliminary sizings based on requirements. It's the product owner's responsibility to

keep the backlog full - those stories are what the team will be working on, with some input from the
http://programmers.stackexchange.com/questions/125510/what-happens-between-sprintshttp://programmers.stackexchange.com/questions/125510/what-happens-between-sprintshttp://programmers.stackexchange.com/questions/125510/what-happens-between-sprints


9/39

product owner regarding priorities. Once the current sprint is done, the next sprint will start, utilizing

the work that we've put in to prepare stories and tasks for the next sprint.

There is some overhead (lots of meetings, Q&A, and requirements evaluations), but overall it works

- we make steady progress with little down time. Sprints have usually lasted either two or three

weeks. QA usually takes place once stories are completed. However, the QA team might have other

tasks that they can do. Regarding story grooming, tasks may fall to senior members of the team, or

the whole team. It can vary depending on the size of the team and the process that's been agreed

upon. Code reviews usually take place while QA occurs, or at the end of the sprint if time is

compressed. And if there's not enough time to finish stories, in practice these stories get pushed to

the next sprint. Proper sizing and estimation is very important here.

5What to do when a sprint is finished early?

What to do when a sprint is finished early?

At the moment our Scrum team works off stories from the backlog, if the sprint is finished early.

What happens with stories taken from the backlog? Will the stories be added to the current Sprint ?

If yes, what if these stories won't be finished in time. Is the Sprint failed then?

Bring something from the project backlog into the sprint (after discussions with scrum master and

project owner).

The size of the item you undertake will depend on how much time you have. If there is nothing

small enough create a sub-task of a bigger task to get it started (ie do some of the preliminary

work).

Alternatively create some tasks that make the code base better. I have never seen a code base that

could not be improved in some way. Review some code add more unit tests etc..

Working on stretch or future sprint backlog items seems to be the common thing to do, which

makes a lot of sense if your sprint backlog items are small enough and clearly defined. However,

backlog items that may place the "done" code into a "no longer done" state should be avoided.

If the sprint is truly finished, tag it, prepare it for delivery, deliver it, and put your source code

repositories into the "next sprint" state so there's no risk that late sprint changes will put delivery at

risk.
http://programmers.stackexchange.com/questions/179183/what-to-do-when-a-sprint-is-finished-earlyhttp://programmers.stackexchange.com/questions/179183/what-to-do-when-a-sprint-is-finished-earlyhttp://programmers.stackexchange.com/questions/179183/what-to-do-when-a-sprint-is-finished-early


10/39

6Handling unexpected features during sprint

Our team is going to adopt scrum and agile technics. We've got a product, which we develop for

multiple customers. This customers supplied us with necessary requirements, so everithing is fine to

adopt agile techinics.

But at some moment (for example during sprint), new customer apears, and he wants to get a

demo of product slightly different from what we have now. This may be some new features or minor

differences in behavior. And he wants to get this demo for example during the week. It is very

important to show that our product supports this features (because otherwise he will address to our

competitors), so we have to develop this features (may be partly) during the week.

How we must handle this sort of features with agile? Move them to current sprint backlog? Or split

one team to two and create another sprint? Or may be there is another way?

If you are doing scrum, you should have a Product Owner, no? It's his or her job to prioritize the

stuff that comes along and manage the relationship with the customers. That said, the product

owner should not be adding items to a sprint unless the team agrees to it and that there are items

that have not been started yet and can be pushed out of the sprint to compensate.

If the new customer results in a second product owner, that makes for a second project. In that

case you should form a second team and create a prioritized backlog for the new project.

If you are running into a lot of this, you might look at kanban as an alternative to scrum.
http://programmers.stackexchange.com/questions/181661/handling-unexpected-features-during-sprinthttp://programmers.stackexchange.com/questions/181661/handling-unexpected-features-during-sprinthttp://programmers.stackexchange.com/questions/181661/handling-unexpected-features-during-sprint


11/39

7Sprint item takes longer then expected to be completed.

What should we do?

What should we do if a item in scrum takes longer then expected? i am asking this because i have

been noticing items that developers is struggling to complete as it is much tougher then initiallythought.

In such situation should we

remove the item from sprint back to product catalog so that we can meet the sprint timeline?

move to easier sprint item and leave problematic sprint till the end of timeline

justify at sprint review why the item cant be completed at current sprint to stakeholders?

How can we avoid such situation in future? Is it due to lack of upfront planning or we did not make

an effort to break down the sprint item into smaller item?

With "item", I suppose you mean "task".

Planning optimism in software is as old as software itself. The good thing about scrum is that you

are facing it soon and create visibility of it: this is why the teams velocity is based on past data and

not future estimates.

To complete a story, you also have to complete the tasks that turn out much harder than

anticipated. No excuse to postpone them. (This is why the Definition Of Done is so important). If

that means that the team is failing a story, then too bad, you will have something to talk about on

your next retrospective. Velocity will go down (become more realistic) and the team will learn to

make better estimates, or leave more safety margin for unforeseen tasks. The product owner will

get a more realistic view on his release planning.

What should we do if a item in scrum takes longer then expected?

Assuming that by item you mean story, at the end of the sprint you typically put it back in the

product backlog (and likely plan it for the next iteration). The team scores zero points for it in the

current iteration.

Another alternative, if the story is big enough, is to slice it vertically. For example, the story "product

catalog search", can possibly be split in "search by category" and "full text search", but not in

"search form" and "search results".

How can we avoid such situation in future?

There is no easy direct answer to this. In scrum you do sprint retrospectives every iteration, where

you typically discuss these kinds of things with the team. There are many different possibilities:

The team, or some team members, has a bad week

Your team pipelines work items horizontally (e.g. backend->frontend->QA)

The stories are too big by mistake
http://programmers.stackexchange.com/questions/204125/sprint-item-takes-longer-then-expected-to-be-completed-what-should-we-dohttp://programmers.stackexchange.com/questions/204125/sprint-item-takes-longer-then-expected-to-be-completed-what-should-we-dohttp://programmers.stackexchange.com/questions/204125/sprint-item-takes-longer-then-expected-to-be-completed-what-should-we-dohttp://programmers.stackexchange.com/questions/204125/sprint-item-takes-longer-then-expected-to-be-completed-what-should-we-dohttp://programmers.stackexchange.com/questions/204125/sprint-item-takes-longer-then-expected-to-be-completed-what-should-we-do


12/39

The team "gold plates" the stories by adding extra work which is not strictly necessary for the

completion of the story.

The stories are very big in nature, you need longer sprints (unlikely)

The team estimates stories imprecisely (incoherently)

The project has a lot of tech debt/rotten code base and your velocity is too low You are not measuring and estimating your sprint capacity correctly (or at all).

8What should a proper Ready for Sprint definition contain?

Teams in our company deal with Product Owners who are in such a position that they cannot spend

as much time with us, as we would like, to do proper Backlog Grooming.

Thus in order to alleviate some of the time constraints we have begun implementing the art of

getting stories "Ready for Sprint" or in other words getting them into a state where we

know/understand enough to take them into a sprint.

Unfortunately we are still new to what would be a proper definition of 'Ready For Sprint' and so the

question of what would be good to keep in mind when getting a story in the backlog Ready for

Sprint?

It should contain enough information that, at the end of the sprint, acceptance is not going to be a

problem.

Sometimes a single sentence is good enough.

Quite often, some team members will want more information/requirements written down to make

sure nobody changes their mind and remembers all that was agreed on.

Anything written down should be as objective/verifiable as possible. I like the 'given/when/then' and

'as ... i ... so that ...' formats quite a lot, as they convey a lot of information and verifiable

requirements in a compact form.

I have seen a couple of attempts at defining 'rules' or gates for the different stages in a story

lifecycle (ready for sprint, accepted...) - and in my experience rules alone don't work well. It's very

easy to end up having an overly exhaustive list of things a story must contain to be considered (use

case, tests plan, mock ups, acceptance criteria, documentation, etc). It's very hard to ensure that

those items are 'good'. And in many cases (simple stories with a lot of shared context or

unsurprising content), mocks, tests plans and details are a waste of time.

An recent example: encouraging 'as X I want to Y', I ended up with 'As an admin, I expect data

confidentiality and integrity to be maintained in the platform.' It meets the guidelines, but is

completely useless at telling dev what they need to deliver/test/document.

I don't think you can get away from having good communication between PO and dev, and a good

feeling about what each side is going to think is good enough.
http://programmers.stackexchange.com/questions/205796/what-should-a-proper-ready-for-sprint-definition-containhttp://programmers.stackexchange.com/questions/205796/what-should-a-proper-ready-for-sprint-definition-containhttp://programmers.stackexchange.com/questions/205796/what-should-a-proper-ready-for-sprint-definition-contain


13/39

9Product Owner introduces ungroomed (unfamiliar, not

estimated) User Story(s) into the Sprint Planning meeting

A problem that I am facing and would like some input into is; a Product Owner introduces

ungroomed (unfamiliar, not estimated) User Story(s) into the Sprint Planning meeting.

The issue that this has caused is the team rushes to understand and estimate the User Story(s),

which puts significant time pressure on the commitment portion of the Sprint Planning meeting. The

team also seems to be unsure of their estimate due to the rushed nature of grooming them in the

Sprint Planning meeting. The end result of this is a rushed, half hearted Sprint commitment, which is

usually an under-commitment due to so much uncertainty.

I have seen two distinctly different causes for the late introduction of the User Story(s):

1. The team is new to Scrum and has been having difficulties grooming stories, prior to planning.

2. A brand new high priority User Story has appeared just before the Sprint Planning meeting.

I have discussed these issues with the Product Owner and we have decided upon on actions, I am

wondering what have you tried when the Product Owner introduces a brand new high priority User

Story just before or even in the Sprint Planning meeting? What worked, what failed?

The team that is having difficulty grooming User Stories in new to Scrum; hence I suspect that some

facilitation of their grooming sessions, mentoring and some time will help them.

Do you have any other suggestions for helping teams come up prompt Planning Poker estimates?

Given they've just been given the story during planning (regardless of it being a new story or not

having estimated it earlier) you have a few choices.

First, you can ask the product owner if the story can be left on the backlog so that it can be properly

checked and estimated during this sprint, and take it next sprint.

If that's not possible, another option is to do it in a spike - a time-boxed story to investigate

something or to try something out - and then you'll have a head start for doing it next sprint.

Finally, if you really must start on it this sprint, then try and find out as much as you can during

planning, and take the story but make it clear of the risk that it may not be completed this sprint. If

it doesn't get completed, so be it, you've done some of it and now know a lot more about it for the

next sprint.

Remember, estimates are just the best estimates with the information you have at the time, and can

be revised later when you have more info.

Also remember you should be spending about 5%-10% of the sprint in refining the backlog. Doing

this really helps keep the planning meetings shorter, more focused and more productive.
http://programmers.stackexchange.com/questions/108454/product-owner-introduces-ungroomed-unfamiliar-not-estimated-user-storys-inthttp://programmers.stackexchange.com/questions/108454/product-owner-introduces-ungroomed-unfamiliar-not-estimated-user-storys-inthttp://programmers.stackexchange.com/questions/108454/product-owner-introduces-ungroomed-unfamiliar-not-estimated-user-storys-inthttp://programmers.stackexchange.com/questions/108454/product-owner-introduces-ungroomed-unfamiliar-not-estimated-user-storys-inthttp://programmers.stackexchange.com/questions/108454/product-owner-introduces-ungroomed-unfamiliar-not-estimated-user-storys-int


14/39

10What to do with unfinished stories and tasks in SCRUM

sprint?

We have unfinished tasks which are part of stories in sprint. They are not accepted by the PO. They

must be included for the next planning of sprint. Obviously the stories must be moved, but whatabout the tasks? Shall they be reopened and moved for the next sprint within the stories or not?

The approach I have used to address these issues is to address them at the next sprint planning

meeting, with choices of:

Do we roll over all unfinished tasks automatically to the next iteration?

Do we review each one and re-evaluate whether we still want that in the next sprint?

Do we look at oustanding tasks before, 'with' (interleaved) or after new items that have been

added?

Do we want to re-vote on outstanding items? Sometimes I have seen items not get done

because they were voted a "2" at the last Sprint Planning but turned out to be more like a 5

(for example), so sometimes the effort determination needs to be revisited.
http://programmers.stackexchange.com/questions/121519/what-to-do-with-unfinished-stories-and-tasks-in-scrum-sprinthttp://programmers.stackexchange.com/questions/121519/what-to-do-with-unfinished-stories-and-tasks-in-scrum-sprinthttp://programmers.stackexchange.com/questions/121519/what-to-do-with-unfinished-stories-and-tasks-in-scrum-sprinthttp://programmers.stackexchange.com/questions/121519/what-to-do-with-unfinished-stories-and-tasks-in-scrum-sprinthttp://programmers.stackexchange.com/questions/121519/what-to-do-with-unfinished-stories-and-tasks-in-scrum-sprint


15/39

11Confused about modifying the sprint backlog during a

sprint

I've been reading a lot about scrum lately, and I've found what seem to me to be conflicting

information about whether or not it's ok to change the sprint backlog during a sprint. TheWikipediaarticle on scrumsays it's not ok, and variousother articlessay this as well. Also my Software

Development professor taught the same thing during an overview of scrum.

However, I readScrum and XP from the Trenchesand that describes a section for unplanned items

on the taskboard. So then I looked up theScrum Guideand it says that during the sprint "No

changes are made that would affect the Sprint Goal" and in the discussion of the Sprint Goal "If the

work turns out to be different than the Development Team expected, then they collaborate with the

Product Owner to negotiate the scope of Sprint Backlog within the Sprint." It goes on to say in the

discussion of the Sprint Backlog:

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the

Daily Scrum. The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint

Backlog emerges during the Sprint. This emergence occurs as the Development Team works

through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed

or completed, the estimated remaining work is updated. When elements of the plan are deemed

unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a

Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development

Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

So at this point I'm altogether confused. Thinking about it, it makes more sense to me to take the

second approach. The individual, specific items in the backlog don't seem to me to be the most

important thing, but rather the sprint goal, so not changing the sprint goal but being able to change

the backlog makes sense. For instance if both the product owner and the team thought they wereon the same page about a story, but as the sprint progressed they figured out there was a

misunderstanding, it seems like it makes sense to change the tasks that make up that story

accordingly. Or if there was some story or task that was forgotten about, but is required to reach

the sprint goal, I would think it would be best to add the story or task to the backlog during the

sprint.

However, there are a lot of people who seem quite adamant that any change to the sprint backlog is

not ok. Am I misunderstanding that position somehow? Are those folks defining the sprint backlog

differently somehow? My understanding of the sprint backlog is that it consists of both the stories

and the tasks they're broken down into.

Anyway I would really appreciate input on this issue. I'm trying to figure out both what the idealistic

scrum approach is to changing the sprint backlog during a sprint, and whether people who use

scrum successfully for development allow changing the sprint backlog during a sprint.
http://programmers.stackexchange.com/questions/149871/confused-about-modifying-the-sprint-backlog-during-a-sprinthttp://programmers.stackexchange.com/questions/149871/confused-about-modifying-the-sprint-backlog-during-a-sprinthttp://programmers.stackexchange.com/questions/149871/confused-about-modifying-the-sprint-backlog-during-a-sprinthttp://en.wikipedia.org/wiki/Scrum_%28development%29#Sprinthttp://en.wikipedia.org/wiki/Scrum_%28development%29#Sprinthttp://en.wikipedia.org/wiki/Scrum_%28development%29#Sprinthttp://en.wikipedia.org/wiki/Scrum_%28development%29#Sprinthttp://forums.construx.com/blogs/johnclif/archive/2009/08/05/scrum-smells-going-along-to-get-along.aspxhttp://forums.construx.com/blogs/johnclif/archive/2009/08/05/scrum-smells-going-along-to-get-along.aspxhttp://forums.construx.com/blogs/johnclif/archive/2009/08/05/scrum-smells-going-along-to-get-along.aspxhttp://www.infoq.com/minibooks/scrum-xp-from-the-trencheshttp://www.infoq.com/minibooks/scrum-xp-from-the-trencheshttp://www.infoq.com/minibooks/scrum-xp-from-the-trencheshttp://www.scrum.org/storage/scrumguides/Scrum_Guide.pdfhttp://www.scrum.org/storage/scrumguides/Scrum_Guide.pdfhttp://www.scrum.org/storage/scrumguides/Scrum_Guide.pdfhttp://www.scrum.org/storage/scrumguides/Scrum_Guide.pdfhttp://www.infoq.com/minibooks/scrum-xp-from-the-trencheshttp://forums.construx.com/blogs/johnclif/archive/2009/08/05/scrum-smells-going-along-to-get-along.aspxhttp://en.wikipedia.org/wiki/Scrum_%28development%29#Sprinthttp://en.wikipedia.org/wiki/Scrum_%28development%29#Sprinthttp://programmers.stackexchange.com/questions/149871/confused-about-modifying-the-sprint-backlog-during-a-sprinthttp://programmers.stackexchange.com/questions/149871/confused-about-modifying-the-sprint-backlog-during-a-sprint


16/39

12 What should I do if one of my Team-Members is Ill or in

Holidays.

- Should I handle it as a PBI Illness or Holidays?

- Should I do nothing?

- Should I include it in the velocity calculation (how?)

- Extending the Sprint length is probably against the rules.

- Other solutions?

Hi Marco,

I like to let the team decide. They are asked to forecast a certain amount of work for their Sprint and should take

holiday and sick time in to account. As a Scrum Master you can remind them of these obstacles, but it is ultimately up

to the team. If they feel they can do just as much work, then let them rise to the occasion. But the odds are that it will

impact your velocity, but so will a lot of other things along the way.

I would certainly avoid extending the Sprint or creating sicktime/holiday PBIs.

13. How long were the iterations (or sprints) on the projects

you worked on?

Agile project methodology moves at a fast pace and you should already have a good idea of the length ofthe iterations for the pending project. Answers of between 1-week to 3-weeks are ideal. If your candidate

has worked on Agile projects which have long iterations (4 weeks or longer), or wildly variable-lengthiterations, it will make sense to determine if this person is comfortable with the iterations as defined for yourproject. A steady set of fixed-length iterations that are fairly short is best. The theory that big companiesneed longer iterations is not based in fact. Weve done many big company projects in the 1 to 2 weekiteration range.

14. Are you a Certified Scrum Master (CSM)? If so, how do

you view the way Scrum projects need to be organized?

Often we use certifications as a golden way to qualify candidates. But be somewhat careful with people who

have gone through the Certified Scrum Master (CSM) training. The goal here is to make sure that yourproject team member is comfortable with structure as each iteration progresses. Is she comfortable workingwith a project manager, or communicating to a team lead? Working inside a large corporation, youpersonally might feel that a project manager or team lead position is required on all but the smallest effort.But certain Agile consultants will insist that project managers are no longer necessary under Agile becauseteams will "self organize." Steer clear of these candidates unless that is clearly the direction you want to go.Does your organization have defined roles and career paths like project manager, tester, business analyst,etc.? Do you have a strategy for muddying those career paths for the employees you bring onto this Agileinitiative? If so, great. If not, avoid the candidates who tell you there is no alternative to self-organization.


17/39

If the person is not a CSM, you may still encounter these issues, so pursue the line of questioning eitherway.

NOTE: There is nothing systemically wrong with self-organization, but as a hiring manager, you need to

know what your own strategy is for Agile adoption and then hire accordingly. I personally havent met manycorporate managers who are terribly comfortable with self-organizing teams.

15. Did you use automated test tools on your projects?

Explain how that worked.

Agile project team members should have experience (or at the very least, the desire) to use automatedtesting tools for regression and performance testing of each iteration. At the end of each iteration you want

to have something that your customer/client can "see." Automated testing allows quick identification andisolation of development defects as well as the ability to test development work completed in previousiterations. Expect the candidate to talk about automated regression testing, continuous integration andtesting and even performance testing techniques and tools. Also expect them to discuss the need for manualtesting as well as automated testing, due to the ever-changing nature of the code base in Agile.

16. Have you done continuous integration on a projectbefore? Describe.

Here you want to get a pretty detailed explanation of how the candidate has used continuous integration onprevious projects. Continuous integration is a set of automated build, integration and test steps thatexecutes against the code base in a configuration management repository. For instance, if you were using

Java and CVS, the CVS repository would have a set of triggers that automatically built, integrated and unittested the code often, perhaps each night, perhaps a few times a week, or even every time someonechecked in new code. Each of these is a valid continuous integration story.

17. Did your iterations overlap? For instance, were the

testers still testing Iteration 6 while Iteration 5 was beingdesigned/developed?

There are many views of how iterative/incremental projects should run under Agile. Overlapping iterations iscertainly one strategy. The danger is to pay attention to the candidate if they say that "iterations shouldnever overlap." This may tell you that the candidate is used to having what is called "multidisciplinaryteams." This type of team consists of a set of generic team members who all have the skills and enthusiasmfor requirements, design, coding and testing and who each participate in those activities almost equally. Ifyour company has defined roles (business analyst, test analyst, etc.) and career paths then this candidatemay have a tough time fitting into your structure. They will want BAs to code and testers to do design. Isthat okay? It is your decision. Again, nothing wrong with multidisciplinary teams, but your organization mustbe able to handle the change if you decide to go that way.

18. Have you used story cards or use cases? Explain how

that worked for the team.

Often, Agile projects are associated with the use of story cards. However, our goal is to simply understand ifour potential team member is comfortable implementing a project (designing, developing, testing, etc) withbusiness information which has been documented in some way. The requirements (story cards or use casesor a combination of both) should have enough information to provide guidelines for developing and testingand also allow the development team to come up with a creative and effective solution. By asking this


18/39

question, you want to understand if your potential team member is comfortable working with requirementsin a structured development environment (versus brief summaries from which the developers build code).Again, this is a matter of matching the Agile candidates experience with your organizations needs.

19. How did you manage traceability of the requirements to

testing?The point here is to make sure testing goes all the way back to requirements for validation. Not only is itimportant to test that the functionality a developer has created during an iteration actually functions, it isalso important to determine if it functions the way the business wanted it to function. Does it meet therequirements defined in the story card / use case? Your team members should understand the importance ofthis concept and if they understand and accept traceability, you should be able to count on this person tohelp you meet project goals.

20. How comfortable are you with ever-changing

requirements?

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 desiredthat 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 shouldnt be so tied to code, astory card or any other component of work that prevents providing a solution which meets the customersneeds. The general idea is that requirements can change a lot at the beginning of the release, and very littleat the end.

21. Did people play multiple roles on your development

team?

Here we get back to multidisciplinary teams. What you are really trying to understand from this question ishow 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 theircareer path, your interview candidate may have difficulty on your team if she is more comfortable working inAgile projects where she has had the ability to play multiple roles (Scrum for example). Conversely, if yourcandidates primary experience was developed on projects where roles were clearly defined and individualsdid 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 yourorganization well and is flexible enough to suit the needs of your Agile project implementation. Twoparticular roles that are more easily interchanged are business analysts and testers, other roles are harderto be "multifunctional."

22. What project management tools were used on your

project?

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


19/39

23. Can you explain the purpose of a burndown chart?

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 "burnedthrough." The work is usually put in terms of a set of "story points" which represent functionality. Once apiece 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 willhave 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, youwant to see how the candidate will link their burndown/burnup chart into your overall project managementstructure.

24. What does project velocity mean?

This is a PM question, but most Agile people should know the answer. Project velocity is the rate at which ateam is "burning" through story points, so a possible velocity might be "30 story points per iteration." Thatmeans 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 viewtowards 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 Agileconsultants or candidate employees. Our hope is that you can build a highly-qualified team that will fit inwell with your corporate development process, culture and PM standards.

25What is Scrum?Scrum is an iterative and incremental agile software development method for managing software projects

and product or application development.

26What is the difference between agile and scrumdevelopment?Agile and Scrum are terms used in project management. The Agile methodology employs incremental and

iterative work beat that are also called sprints. Scrum, on the other hand is the type of agile approach that

is used in software development.Agile itself is not a specific way of working, it is generic set of principles or

priorities which are outlined in the Agile Manifesto. Scrum is a specific flavor of Agile, specifically it is

referred to as an agile project management framework. It draws on the principles of the Agile Manifesto but

goes into detail to define day-to-day activities and how to manage a project in a specific way.

27What are the advantages of Scrum?The sprint process allows for "good enough" development that results in a saleable product even while the

project is in full swing. This incremental delivery system shortens the time to market and may result in

higher revenue, as each completed backlog represents a new release of the product. In addition, reviewing

each sprint before moving to the next means that testing is conducted throughout the process, which allows

teams to change the scope or direction of the project at any point. Although the deadline and budget are

fixed variables, the project requirements are not. In fact, stakeholders and participants anticipate changes

along the way. The product owner's involvement in the project management process facilitates these

changes.

Well, Scrum enables Agility. Three key benefits of Scrum adoption for you are ability to
http://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_agile_and_scrum_developmenthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_agile_and_scrum_developmenthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_agile_and_scrum_developmenthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#What_are_the_advantages_of_Scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#What_are_the_advantages_of_Scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#What_are_the_advantages_of_Scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_agile_and_scrum_developmenthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_agile_and_scrum_developmenthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_scrum


20/39

Respond to changes, while minimizing risk

Increase ROI (return on investment)

Continuously improve

28What are the dis-advantages of Scrum?It can be difficult for the Scrum master to plan, structure and organize a project that lacks a clear definition.

In addition, frequent changes, frequent product delivery and uncertainty regarding the precise nature of the

finished product make for a rather intense project life cycle for everyone involved. Furthermore, the daily

Scrum meetings and frequent reviews require substantial resources. A successful project depends on the

maturity and dedication of all participants, and their ability to maintain consistently high levels of

communication through each backlog and review.

29What is the difference between Scrum and Extreme

Programming?There are major four differences between Scrum and Extreme Programming:

Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long. XP

teams typically work in iterations that are one or two weeks long.

Scrum teams do not allow changes into their sprints. Once the sprint planning meeting is completed and acommitment made to delivering a set of product backlog items, that set of items remains unchanged

through the end of the sprint. XP teams are much more amenable to change within their iterations. As long

as the team hasnt started work on a particular feature, a new feature of equivalent size can be swapped

into the XP teams iteration in exchange for the unstarted feature.

Extreme Programming teams work in a strict priority order. Features to be developed are prioritized by the

customer (Scrums Product Owner) and the team is required to work on them in that order. By contrast,

the Scrum product owner prioritizes the product backlog but the team determines the sequence in which

they will develop the backlog items. Ive never seen a Scrum team not choose to work on the highest-

priority item. And a Scrum team will very likely choose to work on the second most important. However, at

some point one of the high priority items may not be a good fit for the sprint being plannedmaybe a key

person who should work on it will be swamped by work on higher priority items. Or maybe it makes sense to

work on a slightly lower priority item (lets say #10 on the product backlog instead of #6) because the

team will be working in the code where #10 would be implemented.

Scrum doesnt prescribe any engineering practices; XP does. I love the XP engineering practices,

particularly things like test-driven development, the focus on automated testing, pair programming, simple

design, refactoring, and so on. However, I think its a mistake to say to the team youre self-

organizing, we trust you, but you must do these specific engineering practices. This sends a mixed

message to the team that causes confusion. I love the XP practices but dont like mandating them. I want

teams to discover the value on their own.

30What is a Sprint?A sprint is the basic unit of development in Scrum. Sprints last between one week and one month, and are a

"timeboxed" (i.e. restricted to a specific duration) effort of a constant length. Each sprint is preceded by aplanning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint

goal is made, and followed by a review or retrospective meeting, where the progress is reviewed and

lessons for the next sprint are identified.

31What are types of roles in scrum?Scrum teams consist of two types of roles:

Main / Core Roles

Ancillary Roles
http://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_the_dis_advantages_of_Scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_the_dis_advantages_of_Scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_the_dis_advantages_of_Scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_the_dis_advantages_of_Scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_Scrum_and_Extreme_Programminghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_Scrum_and_Extreme_Programminghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_Scrum_and_Extreme_Programminghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_a_sprinthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_a_sprinthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_types_of_roles_in_scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_types_of_roles_in_scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_types_of_roles_in_scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_a_sprinthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_Scrum_and_Extreme_Programminghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_the_difference_between_Scrum_and_Extreme_Programminghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_the_dis_advantages_of_Scrum


21/39

Main / Core roles are often referred to as pigsand ancillary roles as chickens(after the story "The Chicken

and the Pig"

32What are main / core roles in Scrum?The three main / core roles in Scrum are:

Scrum Master:Who ensures the process is followed, removes impediments, and protects the Development

Team from disruption

Product Owner:Who represents the stakeholders and the business

Development Team:A cross-functional, self-organizing team who do the actual analysis, design,

implementation, testing, etc.

33What are Ancillary roles?The ancillary roles in Scrum teams are those with no formal role and infrequent involvement in the Scrum

processbut nonetheless, they must be taken into account.

Stakeholders (customers, vendors):

These are the people who enable the project and for whom the project produces the agreed-upon benefit[s]

that justify its production. They are only directly involved in the process during the sprint reviews.

Managers

People who control the environment.

34What are the types of meetings in scrum?There 6 types of meetings in scrum:

Daily Scrum / Standup

Backlog grooming: storytime

Scrum of Scrums

Sprint planning meeting

Sprint review meeting

Sprint retrospective

35What is Daily Scrum / Standup?Each day during the sprint, a project status meeting occurs. This is called a daily scrum, or the daily

standup.

36What are 3 questions in Daily Scrum / Standup?The three questions in Daily Scrum / Standup are:

What have you done since yesterday?

What are you planning to do today?

Any impediments/stumbling blocks?

37What is Backlog grooming / storytime?The team should spend time during a sprint doing backlog grooming. This is the process of: estimating the

existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking

larger stories into smaller stories.

38What is Scrum of Scrums?It is a meeting each day normally after the Daily Scrum.

These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and

integration.

A designated person from each team attends.

The agenda will be the same as the Daily Scrum, plus the following four questions:

What has your team done since we last met?
http://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_main_core_roles_in_Scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_main_core_roles_in_Scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_Ancillary_roleshttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_Ancillary_roleshttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_the_types_of_meetings_in_scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_the_types_of_meetings_in_scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Daily_Scrum_Standuphttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Daily_Scrum_Standuphttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_3_questions_in_Daily_Scrum_Standuphttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_3_questions_in_Daily_Scrum_Standuphttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Backlog_grooming_storytimehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Backlog_grooming_storytimehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Scrum_of_Scrumshttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Scrum_of_Scrumshttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Scrum_of_Scrumshttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Backlog_grooming_storytimehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_3_questions_in_Daily_Scrum_Standuphttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Daily_Scrum_Standuphttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_the_types_of_meetings_in_scrumhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_Ancillary_roleshttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_main_core_roles_in_Scrum


22/39

What will your team do before we meet again?

Is anything slowing your team down or getting in their way?

Are you about to put something in another teams way?

39What is Sprint planning meeting?At the beginning of the sprint cycle (every 730 days), a Sprint planning meeting is held.

Select what work is to be done

Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team

Identify and communicate how much of the work is likely to be done during the current sprint

Eight-hour time limit

(1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog

(2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog

40What is Sprint review meeting?At the end of a sprint cycle, the Sprint Review Meeting is held.

Review the work that was completed and not completed

Present the completed work to the stakeholders (a.k.a. the demo)

Incomplete work cannot be demonstrated

Four-hour time limit

41What is Sprint retrospective?At the end of a sprint cycle, two meetings are held: the Sprint Retrospective is held.

All team members reflect on the past sprint

Make continuous process improvements

Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be

improved in the next sprint?

Three-hour time limit

42What is Product Backlog?The product backlog is an ordered list of "requirements" that is maintained for a product. It contains Product

Backlog Items that are ordered by the Product Owner based on considerations like risk, business value,

dependencies, date needed, etc. The features added to the backlog are commonly written in story format.

The product backlog is the What that will be built, sorted in the relative order it should be built in. It

is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the stories on

the backlog for the Development Team. The product backlog contains rough estimates of both business

value and development effort, these values are often stated in story points using a rounded Fibonacci

sequence. Those estimates help the Product Owner to gauge the timeline and may influence ordering of

backlog items. For example, if the add spellcheck and add table support features have the

same business value, the one with the smallest development effort will probably have higher priority,

because the ROI (Return on Investment) is higher.

The Product Backlog, and business value of each listed item is the responsibility of the Product Owner. The

estimated effort to complete each backlog item is, however, determined by the Development Team.

43What is Sprint Backlog?The sprint backlog is the list of work the Development Team must address during the next sprint. The list is

derived by selecting stories/features from the top of the product backlog until the Development Team feels it

has enough work to fill the sprint. This is done by the Development Team asking "Can we also do this?" and

adding stories/features to the sprint backlog. The Development Team should keep in mind the velocity of its

previous Sprints (total story points completed from each of the last sprints stories) when selecting

stories/features for the new sprint, and use this number as a guide line of how much "effort" they can
http://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_planning_meetinghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_planning_meetinghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_review_meetinghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_review_meetinghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_retrospectivehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_retrospectivehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Product_Backloghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Product_Backloghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_Backloghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_Backloghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_Backloghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Product_Backloghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_retrospectivehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_review_meetinghttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sprint_planning_meeting


23/39

complete.

The stories/features are broken down into tasks by the Development Team, which, as a best practice, should

normally be between four and sixteen hours of work. With this level of detail the Development Team

understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint

backlog are never assigned; rather, tasks are signed up for by the team members as needed during the

daily scrum, according to the set priority and the Development Team member skills. This promotes self-

organization of the Development Team, and developer buy-in.

The sprint backlog is the property of the Development Team, and all included estimates are provided by the

Development Team. Often an accompanying task board is used to see and change the state of the tasks of

the current sprint, like to do, in progress and done.

44What is Increment?The increment is the sum of all the Product Backlog Items completed during a sprint and all previous sprints.

At the end of a sprint, the Increment must be done according to the Scrum Team's definition of done. The

increment must be in useable condition regardless of whether the Product Owner decides to actually release

it.

45What is Burn down?The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog.

Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for

reference. There are also other types of burndown, for example the release burndown chart that shows the

amount of work left to complete the target commitment for a Product Release (normally spanning through

multiple iterations) and the alternative release burndown chart,[16] which basically does the same, but

clearly shows scope changes to Release Content, by resetting the baseline.

46What is User Story?A feature that is added to the backlog is commonly referred to as a story and has a specific suggested

structure. The structure of a story is: "As a I want to so that " This is done so that the development team

can identify the user, action and required result in a request and is a simple way of writing requests that

anyone can understand. Example: As a wiki user I want a tools menu on the edit screen so that I can easily

apply font formatting.

A story is an independent, negotiable, valuable, estimatable, small, testable requirement ("INVEST

Acronym"). Despite being independent i.e. they have no direct dependencies with other requirements,

stories may be clustered into epics when represented on a product roadmap or further down in the backlog.

47What is Theme?A theme is a top-level objective that may span projects and products. Themes may be broken down into

sub-themes, which are more likely to be product-specific. Themes can be used at both program and project

level to drive strategic alignment and communicate a clear direction.

48What is Epic?An epic is a group of related stories, mainly used in product roadmaps and the backlog for features that

have not yet been analyzed enough to break it down into it's component stories, which should be done

before bringing it into a sprint so to reduce uncertainty. Epics can also be used at a both program and

project level.

49What is Spike?A time boxed period used to research a concept and/or create a simple prototype. Spikes can either be

planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many

sprint delivery objectives. Spikes are often introduced before the delivery of large epics or user stories in
http://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_incrementhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_incrementhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Burn_downhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Burn_downhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_User_Storyhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_User_Storyhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Themehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Themehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Epichttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Epichttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Spikehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Spikehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Spikehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Epichttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Themehttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_User_Storyhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Burn_downhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_increment


24/39

order to secure budget, expand knowledge, and/or produce a proof of concept. The duration and

objective(s) of a spike will be agreed between the Product Owner and Delivery Team before the start. Unlike

sprint commitments, spikes may or may not deliver tangible, shippable, valuable functionality. For example,

the objective of a spike might be to successfully reach a decision on a course of action. The spike is over

when the time is up, not necessarily when the objective has been delivered.

50What is Tracer Bullet?The tracer bullet is a spike with the current architecture, current technology set, current set of best practices

which results in production quality code. It might just be a very narrow implementation of the functionality

but is not throw away code. It is of production quality and rest of the iterations can build on this code.

51What is Point Scale/Effort/Story points?Relates to an abstract point system, used to discuss the difficulty of the story, without assigning actual

hours. The most common scale used is a rounded Fibonacci sequence (1,2,3,5,8,13,20,40,100), although

some teams use linear scale (1,2,3,4...), Powers-of-2 (1,2,4,8...), and Clothes size (XS, S, M, L, XL).

52What are Tasks?Added to the story at the beginning of a sprint and broken down into hours. Each task should not exceed 12

hours, but it's common for teams to insist that a task take no more than a day to finish.

53What is Definition of Done (DoD)?The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires

that all regression tests should be successful.

54What is Velocity?The total effort a team is capable of in a sprint. The number is derived by adding all the story points from

the last sprint's stories/features. This is a guideline for the team and assists them in understanding how

many stories they can do in a sprint.

55What is Impediment?Anything that prevents a team member from performing work as efficiently as possible.

56What is Sashimi?A report that something is "done". The definition of "done" may vary from one Scrum team to another, but

must be consistent within one team.

57What is Abnormal Termination?The Product Owner can cancel a Sprint if necessary. The Product Owner may do so with input from the

team, scrum master or management. For instance, management may wish to cancel a sprint if external

circumstances negate the value of the sprint goal. If a sprint is abnormally terminated, the next step is to

conduct a new Sprint planning meeting, where the reason for the termination is reviewed.

58What is Planning Poker?In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The

Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the

backlog and, as a result, forecast releases based on the team's velocity.

59What is Scrum-ban?Scrum-ban is a software production model based on Scrum and Kanban. Scrum-ban is especially suited for

maintenance projects or (system) projects with frequent and unexpected user stories or programming

errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrums

daily meetings and other practices can be applied, depending on the team and the situation at hand.
http://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Tracer_Bullethttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Tracer_Bullethttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Pointhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Pointhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_Taskshttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_are_Taskshttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Definition_of_Done_DoDhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Definition_of_Done_DoDhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Velocityhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Velocityhttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Impedimenthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Impedimenthttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sashimihttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Sashimihttp://www.questions-interviews.com/software-development-testing-models/scrum.aspx#what_is_Abnormal_Terminationhttp://www.questions-interviews.c

Sprint Team

Documents

Transcript of Sprint Team