Activity Product Planning Create Product Backlog

Product Owner Product Owner is required to make prioritization decisions across the entire spectrum, representing the interest of stakeholders and influenced by the team.

Scrum Master X

Team X

Time Limit X

Create Release Backlog 1. Identify Items 2. Identify definition of "Done" 2. Prioritize each item

Yes

Team Provide Estimate for each item in backlog Assign Business Estimate Value to each item (Use other factors like Risk, ROI etc.)

x Yes

x Help Product Owner to identify estimates, risks etc.

Yes x x

Prioritize Item in Backlog

Yes

Help Product Owner to identify estimates, risks etc.

Sprint Planning - Part One Sprint Planning Part One Product Owner and Team review the highpriority items in the Product Backlog The Product Owner and Team also review the Definition of Done

Yes Yes

Yes

Sprint Planning - Part Two

8 Hrs for 4 Week Sprint 4-6 Hrs Per day

Identify Capacity of each team member Daily Working Time Identify Product Backlog Item that can be completed with in this time frame Breakdown selected items and Create Sprint Backlog Items with estimate Hours The Team decides how much work (item) it will commit to complete,

Yes

Identify Items which can be completed within this sprint (if any)

Daily Scrum

15 Min Every Day x Yes

In the Daily Scrum, one by one, each member of x the Team reports three (and only three) things to the other members of the Team:

Create List of Blocks

Yes (Any assigned Team Member)

Do Follow-up meeting after Scrum Update Sprint Backlog Daily Enter estimate of amount of hrs remaining to complete their current task Generate Sprtint Burndown Chart Yes (All Team Member) 5 Min Every Day

Team can decide to reduce scope of sprint Product Backlog Refinement After Every Sprint

5%-10% of each Sprint OR 4 Hrs for 30Days Yes

Refine Product Backlog items for future Sprints Yes This includes detailed requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items. End of Sprint Conduct a demo of the product finsihed till now. Conduct Sprint Review Meeting. in-depth conversation between the Team and Product Owner to learn the situation, to get advice, and so forth. Repriotize items which do not fall into "Done" category Items that are not done go back to the Product Backlog and will be re-prioritized by the Product Owner.

30Min Max

Yes

Sprint Retrospective

Draw two columns on a whiteboard, labeled What s Working Well and What Could Work Better

Go around the room, with each person adding one or more items to either list. As items are repeated, check marks are added next to them, so the common items become clear. Next Sprint In case of some remaining work, such as final production environment integration testing, and so there will be the need for a Release Sprint to handle this remaining work.

Guidelines
Vision about the project. This backlog exists (and evolves) over the lifetime of the product; Only a single Product Backlog exists; The Product Backlog includes a variety of items, primarily new customer features, engineering goals, exploratory or research work, known defects. The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear,to the Product Owner and Team to decide how much detail is it is up and so forth. required, and this will vary from one backlog item to the next, depending on the insight of the Team, and other factors. State what is important in the least amount of space necessary.

Just make clear what is necessary for it to be understood. Scrum does not define any estimation technique. The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth.

Maximize ROI (choosing items of high value with low effort) this is a continuous re-prioritization activity as the Product Backlog is ever-evolving.

Part One focuses on understanding Product Owner wants.

what the

Done means coded to standards, reviewed, implemented with unit test-driven development (TDD), tested with 100 percent test automation, integrated, and documented. According to the rules of Scrum, at the end of Part One the Product Owner may leave although they must be available (for example, by phone) during the next meeting. However, they are welcome to attend Part Two Part two focuses on understanding that team decide to take on.

how to implement items

their average workday minus the time they spend attending meetings, doing email, taking lunch breaks, and so on. Discuss Product Design

starting with the items that are the highest priority for the Product Owner.

This makes for a more reliable commitment because the Team is making it based on its own analysis and planning, rather than having it decided by someone else. The Team has the ability to lobby for items from further down the list; this usually happens when the Team and Product Owner realize that something of lower priority fits easily and appropriately with the high priority items.

Any change during Sprint must be avoided, untill the start of next meeting. In avoidable circumstances, Product Owner and Scrum Master cancel the sprint. Part two focuses on understanding that team decide to take on.

how to implement items

(1) What they were able to get done since the last meeting; (2) what they are planning to finish by the next meeting; (3) Any blocks or impediments that are in their way. Daily Scrum is not a status meeting to report to a manager; it is a time for a self-organizing Team to share with each other what is going on, to help them coordinate. There is no discussion during the Daily Scrum, only reporting answers to the three questions; if discussion is required it takes place immediately after the Daily Scrum in a follow-up meeting, although in Scrum no one is required to attend this. It is generally recommended not to have managers or others in positions of perceived authority attend the Daily Scrum.

This graph shows, each day, a new estimate of how much work (measured in person hours) remains until the Team s tasks are finished.

One of the lesser known, but valuable, guidelines in Scrum is that five or ten percent of each Sprint must be dedicated by the Team to refining (or grooming ) the Product Backlog.

Sprint end at the decided date, whether the work is completed or not. Anyone present is free to ask questions and give input. Can include any of the stakeholder. Inspect and adapt

In way, there is transparency regarding the quality of the work; Teams cannot fake the quality by presenting software that appears to work well, but may be implemented with a messy pile of poor quality and untested code. It s an opportunity for the Team to discuss what s working and what s not working, and agree on changes to try. The Team and ScrumMaster will attend, and the Product Owner is welcome Agile Retrospectives (Derby, Larsen 2006)

Eeverything is completely finished every Sprint; When necessary, Sprints continue until the Product Owner decides the product is almost ready for release, at which point there will be a Release Sprint to prepare for launch.

Level 1 (Team Level)

Team
A Scrum Master is in place

Level 2 (Department Level)

A Scrum Master is in place

Level 3 (Business Level)

Scrum Masters are in place

The Team has adopted some of the Scrum practices and artifacts but may not use them consistently The process isn t documented and tends to vary by project Agile practices have been self-taught Process is limited to the solution team

The team doesn t understand the language used by the business representatives

Some of the teams have adopted some of the Scrum practices and artifacts and are starting to use them consistently Consistency across the teams is uneven and mostly depends on the leadership and perseverance of a few individuals Some of the process is documented but it tends to vary by team Agile practices have been self-taught or a coach was hired to help the team launch their initiative Process is limited to the department

The 3 Scrum roles are well understood and respected If there is more than 1 Scrum team, a Scrum of Scrum has been put in place External help has been used to achieve this level of maturity Team members are attending Agile conferences

Department
Outside the team, almost nobody has heard or understand what Agile means Other teams are unaware or not interested in the approach used by the Agile team Mostly business as usual Mostly business as usual There is confusion around the roles of: business analyst, architect, database administrators and project managers Agile is sometime discussed in departmental The process is documented and tends to be meetings with some interest from people consistent across projects outside the team immediately impacted An increasing number of teams are adopting External help has been used to properly Agile practices implement the Agile practices

Business
Unaware or not interested in the approach used by the team Business as usual A business analyst acts as the proxy for the business representative Unaware or not interested in the approach used by the team Collaboration between the development team and the business side remains mostly unchanged except maybe for increased interaction between the 2 groups Business decision are still mostly made by business analysts or architects Starting to be aware of the new practices used by some of the teams Mostly resistant to change since they are lacking information about the new process Follow the traditional project management approach Do not consider the Agile approach to be very solid for large scale projects A Product Owner is clearly identified and may be dedicated to their project The concept of incremental and iterative development is gaining more acceptance from the business representatives Process is slowly expanding within the business side

Complains that what the information technologies team delivers is not what is needed or asked for Misunderstanding of the language used for the development team

Product Owners bring some of their colleagues to end-of-sprint demonstrations Starting to be aware of the new practices used by some of the teams Mostly resistant to change since they are lacking information about the new process Follow the traditional project management approach Do not consider the Agile approach to be very solid for large scale projects Awareness is increasing at the director level within IT and Business of the new Agile approach Many assumptions and misunderstanding remain A strong evangelist is in place to promote the new approach and bring together the IT and business side of the organization

Project Managers
Unaware or not interested in the approach used by the team Follow the traditional project management approach

Managers
Unaware or not interested in the approach used by the team Business as usual Unaware or not interested in the approach used by the team Business as usual

Results
Team is slightly more productive Teams that have adopted the Agile approach Project teams using the Agile approach are are slightly more productive more productive Morale is improving Moral of the people using Agile is much higher than those outside the Agile teams Some friction with project managers and people managers remain where most people tend to fall back to their traditional paradigms

Morale is slightly improved

Much friction with project managers, people Productivity varies from one team to the managers and the business as the team next members try to teach people outside the team what Agile is and what it can do for them Some teams productivity is decreasing since they have hit important hurdles Some teams have abandoned the new approach and have gone back to their traditional approach Some friction between the development and the business teams in light of the new

Level 4 (Project Management Level)

There is a clear segmentation between the role of the Scrum Master and that of the project manager If there is more than 1 Scrum team, a Scrum of Scrum has been put in place Interference with the team s activities is almost eliminated The team is autonomous and the Scrum rituals and artifacts are respected and standardized

Level 5 (Management Level)

Scrum Masters are in place

The 3 Scrum roles are well understood and respected If there is more than 1 Scrum team, a Scrum of Scrum has been put in place External help has been used to achieve this level of maturity Team members are attending Agile conferences

The department has adopted many of the Scrum practices and artifacts and are using them consistently Much of the confusion around the roles of: business analyst, architect, database administrators and project managers have been eliminated The process is documented and is consistent across projects External help has been used to properly implement the Agile practices Product Owners are clearly identified and are dedicated to their project The project manager is well accepted and is part of the Product Owner team The concept of incremental and iterative development is fully accepted from the business representatives Process is expanding to the business side

The department has adopted many of the Scrum practices and artifacts and are using them consistently There is no confusion around the various roles surrounding the projects The process is documented and is consistent across projects

Product Owners are clearly identified and are dedicated to their project The project manager is well accepted and is part of the Product Owner team The concept of incremental and iterative development is fully accepted from the business representatives Process is expanding to the management level of the organization Projects managers are fully aware of the new practices used by the teams The traditional project management approach has been adapted to include a more Agile approach Agile is accepted as a solid approach for large scale projects Review the best practices to adapt to changing realities Have fully transferred the authority and responsibility to the teams to allow them to do their job properly

Projects managers are fully aware of the new practices used by the teams Resistance to change has been replaced with adaptation of the traditional approach to include a more Agile approach Agile is accepted as a solid approach for large scale projects

Awareness of the new Agile approach is increasing at director level and above within the IT, Business, and Project Management organizations

Some assumptions and misunderstanding remain for Avoid interference and micromanagement managers Training initiatives have begun for management and Promote collaboration and teamwork attendance is high A strong evangelist is in place at the management / executive level to promote the new approach Support continuous learning and do not systematically penalize failures Adapt their management style to the context of their team Project teams using the Agile approach are more productive The various projects using Scrum are more productive than those using a traditional approach Moral of the people using Agile is much higher than Moral is high all around those outside the Agile teams Friction between traditional roles are being handled Friction around the new approach has disappeared

Strong collaboration between all parties involved Organization is able to quickly react to changes in its environment Management is considering implementing Agile to projects that do not require software

Time box A period of time that cannot be exceeded and within which an event or meeting occurs. For example, a Daily Scrum meeting is time boxed at fifteen minutes and terminates at the end of fifteen minutes, regardless. For meetings, it might last shorter. For Sprints, it lasts exactly that length. Burn Down The trend of work remaining across time in a Sprint, a Release, or a Product. The source of the raw data is the Sprint Backlog and the Product Backlog, with work remaining tracked on the vertical axis and the time periods (days of a Sprint, or Sprints) tracked on the horizontal axis. Daily Scrum A short meeting held daily by each Team during which the Team members inspect their work, synchronize their work and progress and report and impediments to the ScrumMaster for removal. Follow-on meetings to adapt upcoming work to optimize the Sprint may occur after the Daily Scrum meetings. Done Complete as mutually agreed to by all parties and that conforms to an organization s standards, conventions, and guidelines. When something is reported as done at the Sprint Review meeting, it must conform to this agreed definition. Estimated Work Remaining (Sprint Backlog items) The number of hours that a Team member estimates remain to be worked on any task. This estimate is updated at the end of every day when the Sprint Backlog task is worked on. The estimate is the total estimated hours remaining, regardless of the number of people that perform the work.

Ref

Scrum Primer

Risk Management
Risk ID Number Risk Description Impact Rating Probability of Occurrence

Team members are taking other classes which could cause some deliverables to be late or of lesser quality

8.00

80%

Team members' focus is on things other than required deliverables, causing the team to be late or miss key deliverables

9.00

60%

The team does not understand the full needs and desires fo the customer.

10.00

50%

Requirements could creep up on the team, which causes drastic changes to the planned schedule of the project. This could cause some deliverables to be late and make the customer unhappy.

7.00

70%

Overly simple design may lead to missing key issues that call for re-design and re-implementation later in the project

8.00

60%

Overly complicated design may lead to misunderstanding of how the system is working. This could affect the team members as well as the customer when the code is handed over at the end of the project.

9.00

50%

Project schedule is too optimistic

7.00

60%

Customer does not deliver documents and artifacts in a timely manner which could slow down planning, and development speed

8.00

50%

Vaguely specified parts of the product are more timeconsuming than imagined

8.00

50%

10

C# is not well known or known at all by some of the team members

9.00

40%

11

Possible use of GDI+ which is new to some of the team members

7.00

50%

12

The scope of the project is too large for the development team to manage within the timeframe given

8.00

40%

13

Failure to realize some risks ahead of time

8.00

30%

14

The project plan might be abandoned while under pressure to meet a milestone, deliverable or release

7.00

30%

15

User manual created with incorrect information

2.00

75%

16

The scrum process does not work well for this team

7.00

20%

Weighted Impact Rating

Mitigation Strategy
Team member coordination is very important to mitigate this risk. If one member has a very busy week ahead, then they should let the other members know so that their share of work can be distributed accordingly amongst the other group members. Also, team members should let other members know about trips out of town, interviews, appointments and other conflicting activities a week or two in advance to allow the team to properly re-distribute work. Another suggestion would be for student to put more priority on this class over other classes, but is not necessarily recommended.

64.00

54.00

The team can create a more strict schedule for activities to do during the next day, week, or month and plan those activities out to the hour as much as possible. Then the project planners will look over the schedule and make sure that all deliverables are being worked on for enough time, while leaving some slack for optimistic estimates for work time. After times have been distributed to work on deliverables, then the team can distribute any nonmandatory work to be done during any extra time.

50.00

Sometimes it is difficult to understand what it is that the customer really wants and by continually asking questions in carefully worded ways the team can grasp a better understanding of the customers needs. It is important to be persistent about unknown areas of the project while not bombarding the client with too many questions as well.

49.00

The team can use the validation and sign-offs with the client to create a contract of what is required of the system. Once the requirements are agreed upon, verified through the SRS document by the client, and signed-off on there will have to a requirements negotiation phase where the team discussing changes with the requirements. The SRS would then need to be changed, agreed upon, verified by the client again, and signed-off on again. The main goal is to use the SRS document as a contract for how the system behaves.

48.00

The team can spend a lot of time in the design phase as well as use software engineering patterns that are known to work for certain situations. Also, the team can continually review the design to make sure it will cover any case that may come up in the future.

45.00

The team can make sure to create a detailed enough design document to fully explain all the reasoning behind the design for the system. Also, including comments in complicated parts of the code will be helpful as well as using already known design patterns. Another suggestion would be for the team to use code reviews and refactoring sessions to make sure the code is designed properly for the needs and desires of the system.

42.00

The team can schedule activities with a soft deadline and a hard deadline where they aim to get the activity completed by the soft deadline, but if they fail to do that they still have some slack time to meet the hard deadline. Also, the estimated times could be exaggerated to make sure there is enough slack time to get the work done on time. This also calls for starting activities as soon as possible rather than waiting until the later to start something. Just because a deliverable is due later does not mean you have to start it later.

40.00

The team members can try to request document ahead of time so that they are received before they are needed. It is very useful to be able to detect at an early stage when certain documents may be needed to mitigate this risk.

40.00

The team can make sure that all requirements in the SRS are not vague by using requirements techniques to avoid ambiguities. Also, the team can make sure that they fully understand the customer's needs and desires to make sure each part of the system is welldefined. This will allow the team to better understand how much time ti will take to develop each part of the system as well.

36.00

The team members can do tutorials and learn how to program in C# as well as look at various existing examples that can be found online or in text books using Books 24x7 availabe on RIT's Wallace Library Website. If one member knows how to program in C# already and is familiar with the .NET framework they can step up and try to lead the team while developing to make sure all the important concepts are understood across the team.

35.00

The team members can do tutorials and learn how to program using GDI+ as well as look at various existing examples that can be found online or in text books using Books 24x7 availabe on RIT's Wallace Library Website. If one member knows how to program using GDI+ already they can step up and try to lead the team during this phase of development to make sure all the important concepts are understood across the team.

32.00

The scope might be a to able to be modified during one of the requirements negotiation phases. Also, each requirement could explicit state whether it is a must-have feature or a desired feature that would be nice to have. The team members can plan to make sure they get all the required features into the system working correctly before attempting to add desired features.

24.00

The team can constantly review this Risk Management document, re-assess all factors, and even add new risks as the team becomes aware of them. Team members could also be on the lookout for other possible risks by exploring other team's Risk Management documents to see if they have anything in there that this team does not.

21.00

The team could use the Project Plan as a go-to guide of what to do and where to go next. If there is an argument of whether to go against the originally signed-off on Project Plan, then the Project Plan must be reviewed and re-signed-off on before doing something drastically different from the plan.

15.00

The user manual could be created at a late enough time where the solid foundation of the system are pretty much set in stone. If the team starts the user manual too early in the project it is likely to change and contain incorrect information if not updated frequently enough.

14.00

Mission-critical systems as well as banking system tend to follow a more waterfall-like process and scrum might not fit well into a waterfall-like client environment. However, the team could incorporate the waterfall approach simultaneously to using a scrum process. The team would have to use a somewhat modified version of the scrum process in order to achieve this.