Today i was pleased by getting my Scrum Master Certificate , I can’t wait to actually start using it in real life
I think it is a great way of managing and developing software, it just feels right
Here is the description and the rules to get certified here and here
Basically it is taking the course and then participating in an online exam and passes it
I wrote couple of Topics about thing I learned while talking the course
Have a look at them and feel free to ask any questions or help
Overview of the main backlog items (legacy bugs, Infrastructure Items, Analysis Work)
Dividing large Epics into small stories that allow prioritization by PO considering Return on Investment (ROI)
Backlog Items should describe the what not the how they can take the form of User Stories
"As a <some Role> I want <Something> so that <Some Benefit>"
User Stories Should Meet the I.N.V.E.S.T Criteria
On backlog: research Spikes, artifacts required by the organization
Not on backlog: tasks level work (code, design, etc.)
Team estimate tasks by relative team effort, planning poker approach can be used
Includes Product Owner, Scrum Master & Team, PO identifies highest priority backlog items
Team estimates how many items it can complete next iteration, meeting takes 4 hours
Occurs immediately after sprint planning one when PO is gone, team decomposes backlog item into tasks
With effort estimates (4 – 16 hours each), team builds Sprint backlog from those tasks, meeting takes 4 hours
The list of PBIs from the main Product Backlog that the teams commit that they will be able to deliver in the next sprint
Each PBI should be divided into subtasks and prioritized and time estimated
Each PBI should have well defined acceptance criteria description
Done shouldn’t be a big requirement story
PBI story card should contain
PBI story card can be wiki or SharePoint item that the team can access easily
The daily team meeting where member describes there current / past work and problems facing them
The daily scrum happens in front of a task board and burn down chart
The daily scrum contains the following sections
By the burn down chart the team should be able to say how much time is left to complete PBIs
During Sprint review team present to the PO product increments, identify any missing features
Gain acceptance from Product owner and review Sprint Velocity
Sprint Velocity is the sum of PBI values(S, M, L …) completed during that sprint
Sprint velocity is not a measure for performance because it depends on the estimates
If one of the PBI needs refactoring it is considered done and added to sprint velocity
If velocity is not predictable after 3-4 sprints then we have a problem �
First sprint should be confusing
Discussing + what went well and ∆ what should we change about the process
Use sticky notes for writing +and ∆, collect notes from team then group and prioritize them
To be ready for discussion, output should be things we can do to change impediments and
Organizations problems, ∆ notes should be the form of required change not the problems
This is more proactive.
In bad political companies it is better to let the team do it without MS, PO or mangers to feel more open
After each Sprint some new PBIs are introduced and some old PBI needs refactoring
Sometimes Product owner should spend time doing the following
People :
Process :
Artifacts :
What is "Flow" ?
Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus
Full involvement and success in the process of the activity
Flow occurs when:
Scrum is originally the American football meeting the team makes before the actual game
Scrum is a good agile way of developing and planning software programmers
It is basically have the idea of doing not discussing, if you are new to scrum meetings
You will get the impression that scrum wastes a lot of time talking and discussing things
But soon you will know that scrum is about the concept "If it doesn’t work find something else"
Scrum is more focused on the small Item "PBI" to device the big picture,
When working with scrum you have to believe in the idea of you make your small task right it will fit into the big picture right …
You don’t have to design the big picture first like waterfall design … Just focus on the small requirement and it will make the big picture after wards
Scrum is about inspecting things and adapting them, people using scrum should enjoy being
Fearlessness: have no fear of talking out loud about problems or task status
Openness: Open to talk about things and help each other reaching the target
Creative, Common Sense
Agile
is a set of principles for software development that emphasizes frequent delivery of product increments
Time boxes communication & collaboration, focusing in subtasks opposite to water fall which is more the big picture
However the product owner in scrum should make sure everybody knows the big picture
Scrum is a flavor of agile that emphasizes self-organization through
30 days iteration (sprint)
3 Roles (Product Owner, Scrum Master, Scrum Team)
3 Meetings (Sprint Planning, Daily Scrum, Sprint Review)
Presenting Scrum in a simple and small flow
Scrum is not for cowboys or developer heroes because they are not team players
And scrum depends deeply on "Swarming"
All team work together in same task so no one owns a task or specialized with one feature
A very nice break through showing all the new features inside Visual studio 2010 helping with the Agile methods and daily scrums … really amazing how it facilitates alot of staff ;- )
Enjoy
