To define the GOALIn the context that we have decided to use Scrum for the project. So I do not focus us Why should we select Scrum? = How effective it is in practical? …But I define 2 goalsFirst, …I will elaborate, give details, properties, rules on some types of meeting that we often conduct during the 3 sprints. As well for Roles that often call others: Scrum mater, scrum team, or product ownerThen we build a common understanding of requirements for each of those component.
Second part is my favorite.I think all the defined elements such as daily meeting, product owners, product backlog, … are just the output behavior.The reasons, philosophy behind them is more important. They will direct us to properly apply, or even when we want to customize, we still keep the core, we still obtain all the built-in value, benefit of Scrum.
This is a great diagram1. The project is initiated by some stakeholder demanding for a system/product to solve their problems.The idea is rough, without very detailed and in pure business term. 2.They tell their idea to PO. PO will collect all SH’s idea and organize them into a list. Until the list is detailed, fine-grained enough, PO give it to Scrum Team. Scrum team will start many circle of Sprint to process them.3. Each sprint, some item from product backlog is chosen to be implemented, then being broken down into a list of more detailed, actionable task list, called Sprint backlog. Each sprint should be within1-4 weeks. Each working day in sprint will start with a 15-minute daily meeting
http://agilebench.com/blog/the-product-backlog-for-agile-teamsIt’s pretty common to have items in the form of:user stories – representing new functionality; and bugs – representing work to address a defect.Over time you may be a bit more sophisticated an add in:chores – representing work that must be done, but provide no direct business valueepics – representing big user stories. Originally defined as too big to fit in an iteration (the equivalent of a Scrum sprint).prototypes (a form of risk mitigation) – representing proof of concepts that help provide information for decision making around whether some functionality may be valuable.
Team look forward pbis in the futurePurpose: understand the description, do daft estimation. These estimation becomes input for PO to reprioritize pbis Thanks to this grooming, all pbis are well understood before Sprint PlanningParticipants: PO, ScrumMaster, Dev team.
Game rule:Whole team, one featureRaise result at the same timeIf the result is not similar, each member explain their reasonThe important thing is that the team shares an understanding of the scale it is uses, so that every member of the team is comfortable with the scale’s values.
DoD is a checklist of valuable activities required to produce softwareDoD is not static but is informed by reality.
Engaged Teams Outperform Manipulated TeamsThe natural human tendency to be accountable to a peer group contradicts years of habit for workers. Allowing a team to become self-propelled, rather than manipulated through extrinsic punishments and rewards, contradicts years of habit for managers.Heterogeneous teams outperform homogeneous teams at complex work. They also experience more conflict.Disagreements are normal and healthy on an engaged team; team performance will be determined by how well the team handles these conflicts.Bad apple theory suggests that a single negative individual (“withholding effort from the group, expressing negative affect, or violating important interpersonal norms”) can disproportionately reduce the performance of an entire group. Such individuals are rare, but their impact is magnified by a team’s reluctance to remove them. This can be partly mitigated by giving teams greater influence over who joins them
Any information you perceived reflect your action, decision. To a developer, what influences:Your tasks, your technicalFuture of product, relevant feature, how your colleague solve his problem, what is your partner obstacles, how is the reaction of customer, ….
http://qualityswdev.com/2010/02/24/how-transparent-is-scrum/How does Scrum create transparency?A visual (physical) task board is a great tool to raise the team’s visibility of the status of the current Sprint. For me the instant status report for manager type people is a mere side effect. Much more important is the constant feedback for the team – to be aware of the progress within the Sprint. Only with this knowledge can the team be truly self-organizing. This is why I am usually against all these software tools that try to replace a physical task board. Yes, there is a slight overhead to produce index cards and print out the burndown chart, but in my opinion it is minor in comparison to the raised level of transparency. Advocates of Kanban say that the typical Scrum task board with its columns for Backlog, In Progress and Done is not transparent enough. The column In Progress is a black box, hiding states like Analysis or Development. What is the right granularity for your team depends on your context, like the complexity of your development process, team size and others. My advice is to try keeping it as simple as possible without sacrificing transparency.Early feedback is essential to make sure you are doing the right thing and that you are doing it right. It enables the team to discover and correct any errors and misconceptions as soon as possible. Feedback cycles can be applied at every level of development: pair programming, unit tests, acceptance tests, Daily Scrums, Sprints and releases. The time frames of these cycles range from seconds to months and the feedback is coming from different sources: your colleagues, automated tests, the Product Owner and most importantly the users of your product.Future work seems to be predictable. This is achieved by the Product Backlog, which can be examined by anyone anytime. This creates a sense of predictability during the project. Even though most team members barely ever look at it, its existence creates the illusion of anticipation of where the project is heading.Cross-functional teams work together on a common task. In an ideal (software development) world there is no them only an us. More often than not there is a bit of rivalry and tension when developers, testers and DBAs are in separate teams. This is because they don’t understand each others pain points, caused by a lack of communication and transparency between teams. In big organizations they might not even sit in the same office or know each other personally. People tend to be so much more understanding and forgiving when they communicate face to face rather than via email. By putting all needed specialists within the same team, Scrum enables communication between them and makes their needs transparent to each other.
Scrum for a team that have appled Scrum
1 common understanding of some Scrum building blocks
“Scrum is a framework for developing
complex products and systems. It is
grounded in empirical process control
theory. Scrum employs an iterative,
incremental approach to optimize
predictability and control risks.”
Meetings: Daily, S.Review,
Product backlog – Product
Sprint 4 weeks
Sprint planning 8 hours
Daily meeting 15 min (fixed)
Sprint Review 4 hours
Sprint Retrospective 3 hours
Grooming 16 hours
Event time is proportional to Sprint time
No need for meetings not defined in Scrum
Limit overhead for communication: < 20%
• Includes: all items to be made
– Features, functions, requirements
• Important properties
“Asa student, I want to view my grades online so that
I do have to travel all the way long to school to know it ”
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
• Single source of requirements
• A copy of the truth
– Bugs from dev team
testing is within sprint
– Bugs from
ProductOwner/Users are in
the Product Backlog
Definition of Done
DoD is a checklist of valuable activities required to produce software
• Unit tests passs and coverage met standard (85%)
• Code is reviewed (or pair programmed)
• Code standards are met
• Continues integration implemented (auto build, deployment and testing)
• Code is refactored
• Non-functinoal tests pass (scalability, reliability, security, etc.)
• Document is completed
Spring Planning Meeting
Parts of Sprint Planning Meeting
• 1st Part: What will be done?
– Select Product Backlog items
– Determining the Sprint Goal.
– Participants: Product Owner, Scrum Master, Scrum Team
• 2nd Part: How will chosen work get done?
– Participants: Scrum Master, Scrum Team
– Creating Sprint Backlog
Transparent = Vision
You act on what you perceive
Transparent in Scrum
How does Scrum create transparency?
“Scrum is a framework for developing
complex products and systems. It is grounded in
empirical process control theory. Scrum employs
an iterative, incremental approach to optimize
predictability and control risks.” --Ken
Estimation : 2 principles,
Definition of DONE,
Scrum team: cross-.., self-..
Empirical = inspect and
Transparent is all Scrum
• … (and a lot more)