To maintain consistency, we should follow the standard from Scrum.org when talking about this topic.
Thanks Diane and Christian from PwC , and most content from this article come from their workshops.
What is scrum? Scrum is a type of methodology. In this article, we are talking about scrum works as an agile framework for developing, delivering, and sustaining complex products.
Basically, scrum is an type of approach to archive agility in a sense. The word agile was in ‘Manifesto for agile software development’ , which will be explained in another article by me, What is DevOps and what isn’t . In the background of such purpose of agile development, delivering and sustaining software, we have a type of framework called scrum, which will teach us how to archive this in details.
Notice that scrum is just a methodology, so everyone can modify specific approaches below to adapt to real conditions.
The basic unit of scrum is scrum team. Scrum team is made by 3 parts:
Product Owner (PO), Dev team, and Scrum Master(SM)
However, there may be other roles in dev team, here is a table to describe this:
|SM||Ensure scrum happens|
|BA(Dev team)||Write User stories|
|Tech Leader*(Dev team)||Assign Jobs|
|Programmer(Dev team)||Finish tasks|
|QA*(Dev team)||Evaluate & test|
|Designer*(Dev team)||Provide prototype, confirm color & design|
A scrum usually contain specialists from different areas and backgrounds. For example, frond-end programmer and back-end programmer, and PO, BA with non-development background will all be in same team, and share responsibility.
Unlike traditional pattern, where we have PM as a PO-like manager, who talks all responsibility and full right to control the dev team, and we have QA team to test, and BA team to check clients’ requirement. In this pattern, each team just need to do own jobs, and they actually do not need to care if other teams are working fine.
 PO’s job is to have frequent talk with BA and client. From client, he need to know what is needed, and what does client want. From BA, he need to know the status of current development, and how many features/bugs can be done/fixed in what time.
 SM’s job is to ensure scrum is real. A SM will original all kinds of conferences, and make sure everyone follows scrum, and do their jobs. Actually if scrum team make bad software, SM won’t take that responsibility. But if scrum failed, like conference failed, or spint goal failed, then SM was responsible for this.
 BA’s job is to have frequent talk with dev team and PO, also, BA needs to quantify requirements from PO into User Stories . BA should keep watch dev team, to make the dev status of each User Story, and make adjustment with dev team and PO. e.g. If a user story is too complex, or impossible to implement in current technology, BA will receive feedback from dev team, and talk with PO about this.
 Tech Leader can handle tech advisory from BA, explaine complexity. Also, Tech leader can assign user stories to members when a sprint starts.
Sprints is a short-team development period with fixed time length.
A sprint contains these related things:
|Sprint high level planning meeting||Once||Design long-term plan (3-4 sprints)||BA & PO & SM|
|Spring high level estimation meeting*||Before Each Sprint||high level estimation(requirement level)||BA & Leader|
|Spring low level estimation meeting*||Before Each Sprint||low level estimation(user story level)||BA & Leader|
|Spring backlog check||Before Each Sprint||decide which user stories will be in next sprint||BA|
|Sprint Refinement meeting||Before Each Sprint||BA explain user stories in this sprint||Scrum team|
|Sprint Estimate meeting||Before Each Sprint||Dev team choose stories, estimate||Scrum team|
|Daily scrum meeting||Every workday||Everyone must speak: What I’ve done, What I will do, What’s my obstacle||Scrum team|
|Sprint Review meeting||After Each Sprint||How we performed last sprint||Scrum team|
|Sprint Report review||After Each Sprint||Generate report for quantify: burn-down chart, happiness report||BA & SM|
|Nexus Meeting*||Custom||Align other scrum teams’ work||SM|
Among all the meetings, SM will use timebox to control time. One sprint can be described by this image:
1.Every user story will get a estimation with ‘Points’. The value of points must be in Fibonacci sequence, so we can break it down.
In high level estimation, BA will ‘guess’ how many points will be in next sprints. And multiple the result by 120%. (20% for redundancy). This will help BA to share tasks to each sprint equally.
2.In low level estimation,dev team will check each user story, and give it a specific point estimation:
For example, if a user story has 5 points. It means the complexity is equal to a 2-point story plus a 3-point story.
Everyone in dev team should estimate every user story and give their judgement of point
3.After estimation, BA get the total points of this sprint. And SM draw a straight line in burn-down chart. On the last day the rest point should be 0.
Once the current progress curve is higher/lower than this line, SM will know that current progress is behind/ahead estimations.
Only SM can cancel a sprint, but it’s very rare.
User Story is the smallest task for scrum team. A user story is the description of a serious of operations from a type of end user, written by BA.
After PO get a change in requirement, BA will write corresponding User Story, and put it in Sprint Backlog. In sprint planning, scrum team will decide which sprint will handle this User Story. Thus, typically , a User Story will have these states:
We generally use Kanban to overwatch all User Stories like this:
In a sprint, there will be several user stories arranged, and if one user story is too complex, or PO is informed that client do not want this anymore, this user story can be shifted to next sprint or repealed during this sprint.
Actually, sprints is just like a new version in development environment. When a sprint closed, the product in env will be merged with this next version.
However, not every sprint will be released to client.
Nexus is the system to manage multiple scrum teams. The form is usually the Nexus sprint planning
Nexus is a complex system, you can view its guide from THE NEXUS™ GUIDE
If you are confused about the events above, just understand which meetings should be hold.
PDCA Theory : Plan,Do,Check,Act
Requirement refinement meetings
Get user stories ready.
Sprint planning meetings
Confirm the goal of this sprint. Once the goal is confirmed, the goal can not be changed. In rare cases, when the goal is no longer valuable due to changes of market, the goal can be modified. Dev teams should avoid new stories to come in, if it’s a must-do, then other stories should be removed to keep velocity.
Show the value deliveried to PO.
‘How to imporve our vecolity?’, asked by SM.
Product backlog (vision) Anyone can add items in this backlog, and PO will select what should be done
Sprint backlog(plan) TODOs in this sprint Once a story was in sprint backlog, dev teams will be responsible for this.
Product increment Demo ready to show to PO.
Scrum provides many existed approach to help agile development and delivery.
You can follow these resources to learn more about scrum:
The key of scrum is the pattern of operations in scrum teams. Scrum’s main thought is to let people from different areas be in same team, and share responsibility. For example, if PO does not need to take responsibility for the failure of dev team, this is NOT Scrum.
Another point is that Scrum should be agile, and Scrum team should hold Continuous delivery.
Is Scrum useful for every project?
In some project, e.g. a project that could be controlled by senior officials and public officials, scrum is not recommended.
Or, in some long-term project with certain goal, like to build a real building, do research in a cutting-edge project, scrum is not recommended.
Or, in some cases that PM pattern performs better.
What’s PO’s job, can PO be a committee?
PO MUST be a single person, otherwise we don’t know which one to follow. PO defines VISION. prototype, and road-map.
What’s dev team(with BA)’s job?
They make the product backlog (sprint backlog), we sometimes call it PBL. PBL has priority and estimated points.
What time should a sprint last?
1-3 Week(s), generally 2 weeks. Dev team must complete kick off, development and test during this time.
What if dev team member is distributed?
To use PMP may be a better choice. Because we have a powerful PM to control them.
It seems like SM do not engage in development, can we remove SM?
NO. SM must quantify team and calculate VELOCITY to make it possible to improve. And they have to control meetings