________________________________________
rough notes on SCRUM ...
Here are some rough notes from a training course I took on SCRUM for Software Development.
Any mistakes, are my own !
Apparently, SCRUM is not a Methodology, nor is it a Process, but a Framework.
However, in my (brief) experience, SCRUM is very much like a process, where development follows in short iterations (Sprints) of 2-4 weeks, and planning takes place at the start of each Sprint. There is a brief daily stand-up meeting, to keep the whole team informed of progress, and of any obstacles.
________________________________________
SCRUM Overview
- SCRUM is used in several disciplines, not just in sofware development
- self organising team
- short iterations:
- better feedback
- experience with this team, this technology
- this leads to better estimates, for the next iteration
- the team members own the plan
- no need for a PM (Project Manager) !
- appropriate for complex projects
- new technologies
- changing requirements
- emerging requirements
- but not appropriate for simple projects (as SCRUM would only be an overhead)
- cheaper failure (due to the early and frequent feedback)
________________________________________
Main roles, artefacts, and relationships
________________________________________
Additional details
product backlog:
- all requirements that are yet to be fulfilled
- the product backlog can provide a long term estimate, of what can be done (product owner helps with this)
- items are sized (estimates are relatively sized)
- the stakeholders can re-prioritise sized tasks (as they know what will fit in a sprint, from the team's velocity)
sprint backlog:
- requirements -> tasks
- contains a buffer, for unplanned tasks (e.g. for support of production)
product owner:
- a leading role
- the client or the supplier
- prioritises the product backlog
- 1 product owner could work with more than 1 team
- can have a 'super' product owner, who leads other product owners
- can be a team member
- IF a team member, then:
good for feedback
BUT bad for confidence of non-technical customers ?
- pressure team to do more
- NOT the scrum master (in order to protect the team)
- transparency to the customer
scrum master:
- a role
- might be a full time job
- 1 scrum master could work with more than 1 team
- facilitator: communicates between the team and the product owner
- protects the team, from the product owner (from too much pressure)
team:
- size is between 3 and 9 people
- skills: depends on the Product Backlog
sprint planning meeting:
* negotiate what can be done, this sprint
- max time is 8 hours (!)
- only plan for this sprint
- BUT can have a high level plan (milestones)
if the product owner demands is too much work for this sprint, then options to consider are:
- re-prioritise
- make the team bigger (often it is too late: retraining cost)
- make the sprint longer (between 1 and 4 weeks)
daily scrum meeting:
- daily
- 15 minutes maximum (but in practise, is longer)
- need to keep team small
- stand-up meeting
- all same-site people should meet together in the same room
- same place and time, each day
- discuss progress
- 3 questions: what I did ?, what will I do ?, any problems ?
- the meeting is held daily, so that problems are raised earlier
- if re-scheduling is necessary, then the Scrum Master needs to talk to the Product Owner. If the issue is complex, then also include Team Member(s).
sprint (iteration):
- starts with sprint planning meeting
- daily stand-up meetings
- final day:
sprint review
retrospective
sprint review:
- demo
- product owner gives feedback
- what delivered, what not delivered
- max 4 hours
retrospective:
- identify things to improve (in the process)
- max 3 hours
________________________________________
Estimation
- relative sizing
larger tasks are sized, in relation to a known smaller task.
- estimates taken as the average of the estimates given for each task, from the whole team
- team votes on the estimates
- majority rules
- if a requirement is unclear, then need a spike
- for long term estimate: use the Product Backlog
- units of estimation: story points. a story point, is the amount of time estimated to complete a smaller task.
- at the end of each sprint:
count the points done
size the next sprint, by that count
this is the velocity of the team (it takes about 3 sprints to get a good estimate)
spike:
a spike is a research task, which may involve producing a prototype.
________________________________________
Multiple Teams
SCRUM demands that a team is kept small. So, in order to handle larger numbers of staff, we can have a scrum-of-scrums.
Every second day, there is a scrum-of-scrums meeting. some members of each team attend.
Teams may have a consumer-producer relationship.
________________________________________
The End
rough notes on SCRUM ...
Here are some rough notes from a training course I took on SCRUM for Software Development.
Any mistakes, are my own !
Apparently, SCRUM is not a Methodology, nor is it a Process, but a Framework.
However, in my (brief) experience, SCRUM is very much like a process, where development follows in short iterations (Sprints) of 2-4 weeks, and planning takes place at the start of each Sprint. There is a brief daily stand-up meeting, to keep the whole team informed of progress, and of any obstacles.
________________________________________
SCRUM Overview
- SCRUM is used in several disciplines, not just in sofware development
- self organising team
- short iterations:
- better feedback
- experience with this team, this technology
- this leads to better estimates, for the next iteration
- the team members own the plan
- no need for a PM (Project Manager) !
- appropriate for complex projects
- new technologies
- changing requirements
- emerging requirements
- but not appropriate for simple projects (as SCRUM would only be an overhead)
- cheaper failure (due to the early and frequent feedback)
________________________________________
Main roles, artefacts, and relationships
________________________________________
Additional details
product backlog:
- all requirements that are yet to be fulfilled
- the product backlog can provide a long term estimate, of what can be done (product owner helps with this)
- items are sized (estimates are relatively sized)
- the stakeholders can re-prioritise sized tasks (as they know what will fit in a sprint, from the team's velocity)
sprint backlog:
- requirements -> tasks
- contains a buffer, for unplanned tasks (e.g. for support of production)
product owner:
- a leading role
- the client or the supplier
- prioritises the product backlog
- 1 product owner could work with more than 1 team
- can have a 'super' product owner, who leads other product owners
- can be a team member
- IF a team member, then:
good for feedback
BUT bad for confidence of non-technical customers ?
- pressure team to do more
- NOT the scrum master (in order to protect the team)
- transparency to the customer
- a role
- might be a full time job
- 1 scrum master could work with more than 1 team
- facilitator: communicates between the team and the product owner
- protects the team, from the product owner (from too much pressure)
team:
- size is between 3 and 9 people
- skills: depends on the Product Backlog
sprint planning meeting:
* negotiate what can be done, this sprint
- max time is 8 hours (!)
- only plan for this sprint
- BUT can have a high level plan (milestones)
if the product owner demands is too much work for this sprint, then options to consider are:
- make the team bigger (often it is too late: retraining cost)
- make the sprint longer (between 1 and 4 weeks)
daily scrum meeting:
- daily
- 15 minutes maximum (but in practise, is longer)
- need to keep team small
- stand-up meeting
- all same-site people should meet together in the same room
- same place and time, each day
- discuss progress
- 3 questions: what I did ?, what will I do ?, any problems ?
- the meeting is held daily, so that problems are raised earlier
- if re-scheduling is necessary, then the Scrum Master needs to talk to the Product Owner. If the issue is complex, then also include Team Member(s).
sprint (iteration):
- starts with sprint planning meeting
- daily stand-up meetings
- final day:
sprint review
retrospective
sprint review:
- demo
- product owner gives feedback
- what delivered, what not delivered
- max 4 hours
retrospective:
- identify things to improve (in the process)
- max 3 hours
________________________________________
Estimation
- relative sizing
larger tasks are sized, in relation to a known smaller task.
- estimates taken as the average of the estimates given for each task, from the whole team
- team votes on the estimates
- majority rules
- if a requirement is unclear, then need a spike
- for long term estimate: use the Product Backlog
- units of estimation: story points. a story point, is the amount of time estimated to complete a smaller task.
- at the end of each sprint:
count the points done
size the next sprint, by that count
this is the velocity of the team (it takes about 3 sprints to get a good estimate)
a spike is a research task, which may involve producing a prototype.
________________________________________
Multiple Teams
SCRUM demands that a team is kept small. So, in order to handle larger numbers of staff, we can have a scrum-of-scrums.
Every second day, there is a scrum-of-scrums meeting. some members of each team attend.
Teams may have a consumer-producer relationship.
________________________________________
The End
see anything wrong in the above? then do please drop me a line ...
Comments
Post a Comment