1. Introduction to Scrum
Notes from Video: I have tried to type the contents in this video as part of my reference. Please check the video link.
1. Inroduction to Scrum
2. Backlog refinement Meeting
3. Sprint Planning Meeting
4. Sprint Planning Meeting
5. Sprint Review Meeting
6. Sprint Retrospective meeting
Introduction to scrum
1. What is Scrum?
Scrum is framework for dealing with complex work such as new product development. It is an alternative to traditional approach that is more suited to manufacting and construction. Why do we need an alternate approach? Earlier the focus was on execution rather than innovation. People with defined roles used defined model, defined best practices to execute the defined plans which did not change very quickly. It was predictable since we knew what we were trying to accomplish, how we will accomplish it.
Today a lot of predictable and repeatable work is done much faster often by machines. Things change more quickly. In order to stay competitive we need to inspect, adapt more quickly and deal with greater uncertinity. A transparent framework including time boxed and feedback loops can help us master uncertinity. Only learning organizations will be able to keep up with the change. Scrum is a framework that is learning about the work and the processes that is used to do it. It is like chaos put inside a box to
address the uncertinity. It is mostly used to develop software products and may be used for other complex work. Scrum introduces feedback loops encouraging us to examine the product we are building and the processes we use to build that product.
Pradictable(old manufacturing): It is typical to adopt the defined (theorethical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood.
Chaotic (timeboxed)- When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.
Anarchy: usually the old predictable model ends in anarchy
Scrum is associated with Agile movement described as Agile Manefesto. Manifesto for Agile Software development: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
We value Individuals and interactions over processes and tools
Working Software over comprehenchive documentation
Customer collaboration over contract negotiation
Responding to changes over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The basic intent of all the agile approach is similar in the sense, we have early and sustainable rate of value feature delivery. Early in the product development cycle we want to see some features working rather than one huge release in the end. Ideally, we will be able to continue incremental improvements indefinately. Product development is ongoing with frequent releases rather than one shot project.
Scrum is not about the attempt to use the traditional Gantt (Requirement analysis, design, code, integration, test, deploy) ideas for developing software that was once authored by Dr Winston Royce in 1970. He drew a picture showing a series of phases. One phase connected to the next phase and again to the next phase and so on and each one has a hand off. We do the analysis in the beginning and when done we start the design then write the code then integrate, then test and finally deploy. This could work if we had perfect knowledge in the beginning and never made mistakes along the way or it never changed along the way.
The next sentence in Dr. Winston Royce paper stated that "I believe in this concept but, the implementation described above is risky and invites failure." The reason it fails with the complex work is because we do not have perfect knowledge in the beginning. In fact we know less about the project in the beginning. The plan driven approach requires us to make our most important decisions right after the initiation when we know the least. Waterfall projects eventually decends in anarchy.When the actual work finally happens, it is with low quality and too much over time.
Scrum is like adding all those phases in the blender. All the ingredients are mixed into every sprint. Instead of driving the work into different phases, we divide into fixed length iterations called sprints. Every Sprint contains some combination of analysis, design, actual implementation, testing, planning for the future if we will be shipping or deploying more frequently.
Right from the first sprint, scrum team will deliver a working, tested, shippable product increment even if it starts out small. Every sprint they demonstrate what a little bigger shippable increment product to everyone. Customers often needs to see the wrong part for them to specify what they really need. With short iteration and more feedback, we have a better chance of discovering the right part. While the product owner does not have to ship every sprint, it is the teams job to make it possible. Sprints
are usually 30 days long and most teams are doing in 2 weeks. To make a shippable product every two weeks, we need people with skills for business requirements, design, coding, testing and they are cross- functional self organizing team. Instead of waiting to test at the end, we start testing increments in the very first sprint. Instead of all the design upfront, we do the incremental design in every spring until it becomes continuous design. We do a small amt of continiuous redesign and refactoring to avoid technical death. Every sprint combines all aspects of the work. The scrum team should collaborate together instead of working in phases during handoff. Scrum brings challenges to individuals, teams and organizations. If it is not distracting the organization, then we are not doing scrum. Scrum is hard to practice. The purpose of scrum with strict rules is to reveal organizations impediments that we can start fixing if we have the courage and commitment. It takes courage and commitment. Healing the organizations impediment exposed by trying to use scrum are more important than doing scrum. The path to masterly starts with learning the framework properly.
2. Scrum Elements: Scrum provides a structure of roles, meetings, artifacts. There are only 3 roles as specified by scrum. a. Product Owner, b. Scrum Master c. Scrum development team.
The product owner is a single individual responsible for Return On Investment (ROI) of product development effort, he has the influence of proritization of product backlog, Final arbiter of requirements questions. It does not mean he will give the details of all the requirements upfront or in detail every sprint, but he does make the final call of those things. Product owner must have the vision behind the product development. It often does not make sense to make a detailed roadmap when there is uncertinity in the future but a vision is important. The team has to work thro' the product owner to get what they want. He is one person who makes proritization decision for that team. He makes the business decision for that team, focused more on the what than on the how.
Scrum development team: It is cross-functional group, they are resposible and attempt to build a "potentially shippable product increment" every sprint, they collaborate and are self-oranizing. If we keep the same team together in the right environment full time with effective retrospective sprint after sprint. They may become a learning team building block of the learning organization. There are no exteranally imposed hirarchy or job titles on this team. it opens the leadership to emerge naturally to
control the flow from person to person naturally. The scrum team is a small group of people, ideally from 4-9 people team ideally feature teams with minimal inter-dependaencies. Team collaboration emerges natually in a team room. If spread in different parts of the world, we may be suffering from collaboration and coordination.
Scrum will quickly bring this problem to the surface. We may experience breakthrough by getting remote people in one room for one or two sprints in the beginning and every few months after that. Information sharing tools help with the practical problem of sharing information. Tools by themselves do not transform organizations.
Scrum Master: Has no management authority, does not have a project manager role and is a facilitator. " If I am your scrum master, you are not my scrum slave." It is just the opposite. Scrum master has no authority over the team. Scrum master is not a project manager. The responsibility of the project manager is split up between the product owner and the team with the scrum master acting like a facilitator. The scrum master protects the team from distractions and interruptions. Gets things done backing natural team organization, removes impediments impacting the team, facilitates the process, teaches how to use scrum, promotes improved engineering practices. Enforces timeboxes, provides visibility, somehow all the above without the authority of a management power.
"Example ScrumMaster Checklist" -(http://www.open.collab.net/media/pdfs/scrummasterchecklist.pdf)"
Artifacts: The two important artifacts are product blacklog and Sprint backlog. The product backlog is a one dimentional list of everything we might ever do. It is a customer- centric features proritized by the product owner, it is a list of everthing we might ever do. If it is not in the backlog, it does not exist. Anyone can add items to the product backlog, the product owner has to proritize it, and the scrum master has to make it visible, A well formed product backlog does not contain task, but has only well formed product backlog items (PBI), which might be in a user- story form or user case scenarios. Forced ranked means there is only one thing in the top position. Getting organizations to do this is a breakthrough.
The sprint backlog is what we have committed to do now. It has an end date and it has the committed backlog items representing the what and the sprint task representing the how (Not started, in progress, completed)
Meetings in scrum: There are 4 meetings in scrum: sprint Planning meeting, Daily scrum, sprint review meeting, and the Sprint retrospective meeting (plus backlog refinement meeting).
Two week sprint (wk 1 M-F and wk 2-M-F)Wk -1 Monday- Sprint planning meeting (4 hours- 9 am to 1 pm), wk 2 Wed Backlog Refinement Meeting ( 2 hours 1-3pm), Sprint review meeting 2nd friday (2 hrs 10-12) noon and again 2nd week Friday (2 hours 1-3pm).
Sprint Planning meeting: The team and the product owner negotiates which items gets the proirity to be committed to the sprint. The teams picks top priority items from the product backlog and commits them to the sprint backlog and makes them into smaller task and decides the right amount of work to do and if they are clear aboutwhat work to do. They plan one sprint.
During sprint execution, the team meets once per day (15 mins stand up or)the daily scrum meeting, before collaborating the meeting. One official meeting where we stand up and report to each other, not to the scrum master, not to Product owner just to the team what I did yesterday and I am going to do today and what are the impediments. All members of the team give the same report to the rest of the team.
At the Sprint review meeting, the team demonstrates a potentially shippable increment to the product owner, and anyone else who may be interested like stakeholders. Product owner will declare which items are done, which items did not meet the requirements (potential shippable increment), measure velocity and get feedback from stakeholders as to how we are doing with them. A lot of time the feedback is you did what you said you will do or we realize that we need something else. We could not have known that until we saw the functioning product increment(wrong product increment.) So, it is during the sprint review meetings we get a lot of feedbacks of the product against requirements.
Every sprint ends with sprint retrospective meeting for the team to inspect the wrong process. The way we inspect and adapt the way we worked together in the last iteration. We talk about what went well, what could be improved, what we learnt, what puzzles us. We give feedback to each other. These things comes out in retrospective are improvement of techniques. The team takes ownership to their process. Regular retrospective meetings provide regular feedback to the process and the team uses to build the process.
Backlog refinement meeting: the team and the product owner get together and decide on the product backlog items for the next couple of sprint. they clarify them, group the big product backlog items or epics into smaller tasks or split them into user stories so that they can do a few of them in a sprint. They get input about proritization,dependancy. Also found in sprint meeting, but people prefer to do it in a seperate meetings.
To learn about sprint, download
Scrum Reference Card, Example Scrummaster's checklist
Notes from Video: I have tried to type the contents in this video as part of my reference. Please check the video link.
1. Inroduction to Scrum
2. Backlog refinement Meeting
3. Sprint Planning Meeting
4. Sprint Planning Meeting
5. Sprint Review Meeting
6. Sprint Retrospective meeting
Introduction to scrum
1. What is Scrum?
Scrum is framework for dealing with complex work such as new product development. It is an alternative to traditional approach that is more suited to manufacting and construction. Why do we need an alternate approach? Earlier the focus was on execution rather than innovation. People with defined roles used defined model, defined best practices to execute the defined plans which did not change very quickly. It was predictable since we knew what we were trying to accomplish, how we will accomplish it.
Today a lot of predictable and repeatable work is done much faster often by machines. Things change more quickly. In order to stay competitive we need to inspect, adapt more quickly and deal with greater uncertinity. A transparent framework including time boxed and feedback loops can help us master uncertinity. Only learning organizations will be able to keep up with the change. Scrum is a framework that is learning about the work and the processes that is used to do it. It is like chaos put inside a box to
address the uncertinity. It is mostly used to develop software products and may be used for other complex work. Scrum introduces feedback loops encouraging us to examine the product we are building and the processes we use to build that product.
Pradictable(old manufacturing): It is typical to adopt the defined (theorethical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood.
Chaotic (timeboxed)- When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.
Anarchy: usually the old predictable model ends in anarchy
Scrum is associated with Agile movement described as Agile Manefesto. Manifesto for Agile Software development: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
We value Individuals and interactions over processes and tools
Working Software over comprehenchive documentation
Customer collaboration over contract negotiation
Responding to changes over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The basic intent of all the agile approach is similar in the sense, we have early and sustainable rate of value feature delivery. Early in the product development cycle we want to see some features working rather than one huge release in the end. Ideally, we will be able to continue incremental improvements indefinately. Product development is ongoing with frequent releases rather than one shot project.
Scrum is not about the attempt to use the traditional Gantt (Requirement analysis, design, code, integration, test, deploy) ideas for developing software that was once authored by Dr Winston Royce in 1970. He drew a picture showing a series of phases. One phase connected to the next phase and again to the next phase and so on and each one has a hand off. We do the analysis in the beginning and when done we start the design then write the code then integrate, then test and finally deploy. This could work if we had perfect knowledge in the beginning and never made mistakes along the way or it never changed along the way.
The next sentence in Dr. Winston Royce paper stated that "I believe in this concept but, the implementation described above is risky and invites failure." The reason it fails with the complex work is because we do not have perfect knowledge in the beginning. In fact we know less about the project in the beginning. The plan driven approach requires us to make our most important decisions right after the initiation when we know the least. Waterfall projects eventually decends in anarchy.When the actual work finally happens, it is with low quality and too much over time.
Scrum is like adding all those phases in the blender. All the ingredients are mixed into every sprint. Instead of driving the work into different phases, we divide into fixed length iterations called sprints. Every Sprint contains some combination of analysis, design, actual implementation, testing, planning for the future if we will be shipping or deploying more frequently.
Right from the first sprint, scrum team will deliver a working, tested, shippable product increment even if it starts out small. Every sprint they demonstrate what a little bigger shippable increment product to everyone. Customers often needs to see the wrong part for them to specify what they really need. With short iteration and more feedback, we have a better chance of discovering the right part. While the product owner does not have to ship every sprint, it is the teams job to make it possible. Sprints
are usually 30 days long and most teams are doing in 2 weeks. To make a shippable product every two weeks, we need people with skills for business requirements, design, coding, testing and they are cross- functional self organizing team. Instead of waiting to test at the end, we start testing increments in the very first sprint. Instead of all the design upfront, we do the incremental design in every spring until it becomes continuous design. We do a small amt of continiuous redesign and refactoring to avoid technical death. Every sprint combines all aspects of the work. The scrum team should collaborate together instead of working in phases during handoff. Scrum brings challenges to individuals, teams and organizations. If it is not distracting the organization, then we are not doing scrum. Scrum is hard to practice. The purpose of scrum with strict rules is to reveal organizations impediments that we can start fixing if we have the courage and commitment. It takes courage and commitment. Healing the organizations impediment exposed by trying to use scrum are more important than doing scrum. The path to masterly starts with learning the framework properly.
2. Scrum Elements: Scrum provides a structure of roles, meetings, artifacts. There are only 3 roles as specified by scrum. a. Product Owner, b. Scrum Master c. Scrum development team.
The product owner is a single individual responsible for Return On Investment (ROI) of product development effort, he has the influence of proritization of product backlog, Final arbiter of requirements questions. It does not mean he will give the details of all the requirements upfront or in detail every sprint, but he does make the final call of those things. Product owner must have the vision behind the product development. It often does not make sense to make a detailed roadmap when there is uncertinity in the future but a vision is important. The team has to work thro' the product owner to get what they want. He is one person who makes proritization decision for that team. He makes the business decision for that team, focused more on the what than on the how.
Scrum development team: It is cross-functional group, they are resposible and attempt to build a "potentially shippable product increment" every sprint, they collaborate and are self-oranizing. If we keep the same team together in the right environment full time with effective retrospective sprint after sprint. They may become a learning team building block of the learning organization. There are no exteranally imposed hirarchy or job titles on this team. it opens the leadership to emerge naturally to
control the flow from person to person naturally. The scrum team is a small group of people, ideally from 4-9 people team ideally feature teams with minimal inter-dependaencies. Team collaboration emerges natually in a team room. If spread in different parts of the world, we may be suffering from collaboration and coordination.
Scrum will quickly bring this problem to the surface. We may experience breakthrough by getting remote people in one room for one or two sprints in the beginning and every few months after that. Information sharing tools help with the practical problem of sharing information. Tools by themselves do not transform organizations.
Scrum Master: Has no management authority, does not have a project manager role and is a facilitator. " If I am your scrum master, you are not my scrum slave." It is just the opposite. Scrum master has no authority over the team. Scrum master is not a project manager. The responsibility of the project manager is split up between the product owner and the team with the scrum master acting like a facilitator. The scrum master protects the team from distractions and interruptions. Gets things done backing natural team organization, removes impediments impacting the team, facilitates the process, teaches how to use scrum, promotes improved engineering practices. Enforces timeboxes, provides visibility, somehow all the above without the authority of a management power.
"Example ScrumMaster Checklist" -(http://www.open.collab.net/media/pdfs/scrummasterchecklist.pdf)"
Artifacts: The two important artifacts are product blacklog and Sprint backlog. The product backlog is a one dimentional list of everything we might ever do. It is a customer- centric features proritized by the product owner, it is a list of everthing we might ever do. If it is not in the backlog, it does not exist. Anyone can add items to the product backlog, the product owner has to proritize it, and the scrum master has to make it visible, A well formed product backlog does not contain task, but has only well formed product backlog items (PBI), which might be in a user- story form or user case scenarios. Forced ranked means there is only one thing in the top position. Getting organizations to do this is a breakthrough.
The sprint backlog is what we have committed to do now. It has an end date and it has the committed backlog items representing the what and the sprint task representing the how (Not started, in progress, completed)
Meetings in scrum: There are 4 meetings in scrum: sprint Planning meeting, Daily scrum, sprint review meeting, and the Sprint retrospective meeting (plus backlog refinement meeting).
Two week sprint (wk 1 M-F and wk 2-M-F)Wk -1 Monday- Sprint planning meeting (4 hours- 9 am to 1 pm), wk 2 Wed Backlog Refinement Meeting ( 2 hours 1-3pm), Sprint review meeting 2nd friday (2 hrs 10-12) noon and again 2nd week Friday (2 hours 1-3pm).
Sprint Planning meeting: The team and the product owner negotiates which items gets the proirity to be committed to the sprint. The teams picks top priority items from the product backlog and commits them to the sprint backlog and makes them into smaller task and decides the right amount of work to do and if they are clear aboutwhat work to do. They plan one sprint.
During sprint execution, the team meets once per day (15 mins stand up or)the daily scrum meeting, before collaborating the meeting. One official meeting where we stand up and report to each other, not to the scrum master, not to Product owner just to the team what I did yesterday and I am going to do today and what are the impediments. All members of the team give the same report to the rest of the team.
At the Sprint review meeting, the team demonstrates a potentially shippable increment to the product owner, and anyone else who may be interested like stakeholders. Product owner will declare which items are done, which items did not meet the requirements (potential shippable increment), measure velocity and get feedback from stakeholders as to how we are doing with them. A lot of time the feedback is you did what you said you will do or we realize that we need something else. We could not have known that until we saw the functioning product increment(wrong product increment.) So, it is during the sprint review meetings we get a lot of feedbacks of the product against requirements.
Every sprint ends with sprint retrospective meeting for the team to inspect the wrong process. The way we inspect and adapt the way we worked together in the last iteration. We talk about what went well, what could be improved, what we learnt, what puzzles us. We give feedback to each other. These things comes out in retrospective are improvement of techniques. The team takes ownership to their process. Regular retrospective meetings provide regular feedback to the process and the team uses to build the process.
Backlog refinement meeting: the team and the product owner get together and decide on the product backlog items for the next couple of sprint. they clarify them, group the big product backlog items or epics into smaller tasks or split them into user stories so that they can do a few of them in a sprint. They get input about proritization,dependancy. Also found in sprint meeting, but people prefer to do it in a seperate meetings.
To learn about sprint, download
Scrum Reference Card, Example Scrummaster's checklist
No comments:
Post a Comment