What is Moscow Rule In Scrum? November 29, 2007
Posted by editor in Agile Practices, Scrum.2 comments
MoSCoW rule
When working with stories from a product backlog especially during release planning, Write all the epic stories ( the main use cases ) and instead of stank ranking them numerically, apply the
- Must Have,
- Should Have
- Could Have
- Wont Have
rule to each story . i.e. ask the product manager to write a M S C or W in front of every story. Sometimes product owners find it tough to apply numbers but a grouping like this is much easier for a first pass.
Is architecture in an agile project done ‘back of the napkin’ ( Paper Napkin Design ) November 27, 2007
Posted by editor in Agile Practices.add a comment
Agile does not mean paper napkin architecture. On a system that is large scale the team needs to be thinking about architecture at all times. This does not necessarily translate to lots of upfront architecture.
But key architectural / design issues should be verified using spikes or conceptually to some extent, to to address key tenets of architecture like layering, tight coupling, scalability, testablity etc.
A paper napkin architecture is just a way the pair discusses about the story before they start developing the story.
Agile teams esp XP teams consisting of senior developers can pull off with Just in time architecture. But in most cases the team consists of a mix of developers and to expect every member to contribute to the evolution of architecture is a challenging task.
An architecture vision and some detailed archicture analysis ( may be for a sprint or two) is good for the overall health of the system.
http://www.agilejournal.com/articles/articles/scaling-agile-development-via-architecture.html
What is the most important role in a scrum team? November 27, 2007
Posted by editor in Agile Practices, Scrum.add a comment
Unquestionably this is the product owner.
Product owner is the the hub of the scrum team. They can make or break the team. The reason for this is that they hold the key to the story box. They are the visionaries ( sort of a product manager). At times they are also proxying for others. Many scrum projects fail solely because the product owner did not perform his role well.
The important functions among others of a product owner in no particular order are:
- Own the product backlog and in doing so the check book.
- Be the sole voice for requirements that the team can trust.
- Be the mediator to other interested parties in the organization and allow other stake holders to make thier case
- Communicate with the management on the status of the project.
- Be the main anchor in a sprint planning meeting.
- Prepare the backlog every sprint for the next sprint or so. Capture lots of detail for the upcoming stories while thinking a bit about the stories for future sprints.
- Be able to articulate what it would take for a developer so that he /she can accept the story as done.
- Do bug triaging.
- Train the users as the visionary of the product.
What is a team ground rule or team working agreement November 21, 2007
Posted by editor in Agile Practices, Scrum.add a comment
By definition an agile team has a high amount of daily interaction. This brings out a need to establish some common set of rules that all team members abide by.
This is a simple document which can be changed every iteration or sprint or necessary. Anything goes here that all developers agree.
Common things added in this list are:
1) Core time that the team members will be present. In case of a distributed team this would define the core overlap time the distributed teams will meet
2) Time of stand up.
3) How much pairing hours are considered good. An ideal pairing day could consist of any where from 2 – 6 pairing hours for example
This document is visited every interation and changes are made. This is one of the visible indicators that should be in the area where the teams are working.
Here is an actual example of one such document from a highly productive scrum team
- Tell the Truth.
- Use the Impediment Backlog for blocking issues
- Address any issues to the correct party (at the right time).
- Meetings: Be on time, end on time, have an agenda
- Communicate individual schedule
- Use sticky note on monitor, email, phone call, etc.
- Update backlog before SCRUM daily
- Be present for core hours: 10:00AM – 5:00PM
- Communication – to the best of our ability
- Publish phone numbers & Calendar
- SCRUM is at 11:00AM Pacific Time
- If unavailable for SCRUM, communicate status
- Test Driven Development is a requirement for the project.
- Pairing or code reviews are required for any shipping code
- Part of requirements for DONE criteria
- When pairing, turn off distractions (email, IM)
- Define and adhere to DONE criteria for stories
- Record Accurate (actual) hours
- Define and adhere to Version Control rules
- Don’t break the CI build!
What is a story point ? November 13, 2007
Posted by editor in Agile Practices, Scrum.11 comments
Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story.
In simple terms its a number that tells the team how hard the story is.
In most cases a story point range is
1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large
It is a relative term and does not directly co relate to actual hours . Since story points have no relevance to actual hours, it makes it easy for scrum teams to think abstract about the effort required to complete a story.
This also creates a lot of confusion as most scrum masters who come from a PMP background relate this immediately to hours.
Story points do give some indication of how much time time was spent in a sprint.
Example lets say at the end of a 10 day sprint a team of 4 covers 40 story points.
10 days = 10 * 8 working hours = 80 hours. = 320 total hours as there are 4 developers.
That equated to 160 pairing hours.
160 divided by 40 = 4 hours pair hours per story point.
