Definitions
1. User Stories: User stories are a set of sentences that describe what the user experiences while using the software. These can be derived from the wireframes; design comps aren’t a requirement.
2. Backlog: These user stories go into a “Backlog”. This backlog is a list of all the user stories, say 50… or a hundred. How many user stories you have are irrelevant. What’s important is that they are all documented in one place called the Backlog. You need to ensure all of the user stories are valid with the stake holders. It also helps to go over them with your entire team to ensure they make sense to everyone involved.
3. Point System: Once you are done with your backlog, you then have your team go through and assign points to each user story. To do that, you need a Point System. A point system is defining a metric for “how challenging something is”. In simple terms, a 1 is easy and a 5 is hard. It doesn’t have to be 1 through 5; it could be 1 through 10 or whatever. It’s best if they are numeric values because you use the points to measure a variety of statistics about your project. Additionally, each team may have their own definitions of what is challenging. While it’s best to use the same 1-whatever metric for the client and server team, the server team will most likely think creating a new server-side method a “1-easy” whereas a client developer a “5-hard”.
4. Sprint: Sprints are a period of time that your team works on their assigned user stories. A sprint is however long your team decides it should be to get a working build with the user stories assigned. This could be one week, two, or a month. It’s important to note the “uninterrupted” part. The client and project manager won’t interject user stories mid-sprint, nor modify your work load. Basically, they don’t bother you. This allows your team to focus on the task at hand, prevent fire drills, and stay productive.
5. Daily Stand-ups: Each team member goes around talking about what they have completed yesterday, this morning, and what they plan for rest of the day. Team also cites’ any roadblocks or issues, and if that involves another team member, They just schedule a separate call, or time to talk over IM, with that specific person.
Roles
Several roles are defined in Scrum; these are divided into two groups; pigs and chickens, based on a joke about a pig and a chicken.
· “Pig” roles
The Pigs are the ones committed to the project in the Scrum process – they are the ones with “their bacon on the line.”
1. Product Owner
The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes user stories, prioritizes them and then places them in the product backlog.
2. ScrumMaster (or Facilitator)
Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks in hand.
3. Team
The team has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (designer, developer, tester, technical communicator, etc.).
Chicken roles are not part of the actual Scrum process, but must be taken into account. An important aspect of an Agile approach is the practice of involving users, internal business groups and stakeholders into portions of the process. It is important for these people to be engaged in the outcome of the project by providing feedback into the development, its review and planning for each sprint.
1. Users
The software is being built for someone. “If software is not used”—much like “the tree falling in a forest” riddle—”was it ever written?”
2. Stakeholders (customers, vendors)
These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews.
3. Managers
People who will set up the environment for the product development organizations.
Meetings
1. Daily Scrum
Each day during the sprint, a project status meeting occurs. This is called a “scrum”, or “the daily standup”. The scrum has specific guidelines:
§ The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)
§ All are welcome, but only “pigs” may speak
§ The meeting is timeboxed at 15-20 minutes depending on the team’s size
§ All attendees should stand (it helps to keep meeting short)
§ The meeting should happen at the same location and same time every day
During the meeting, each team member answers three questions:
§ What have you done since yesterday?
§ What are you planning to do by today?
§ Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)
2. Sprint Planning Meeting
At the beginning of the sprint cycle (every 15–30 days), a “Sprint Planning Meeting” is held.
§ Select what work is to be done
§ Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
§ Identify and communicate how much of the work is likely to be done during the current sprint
§ Eight hour limit
3. Sprint Review Meeting
At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective“
§ Review the work that was completed and not completed
§ Present the completed work to the stakeholders (a.k.a. “the demo”)
§ Incomplete work cannot be demonstrated
§ Four hour time limit
4. Sprint Retrospective
§ All team members reflect on the past sprint.
§ Make continuous process improvement.
§ Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
§ Three hour time limit
Artifacts
The product backlog is a high-level document for the entire project. It contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritised by business value. It is the “What” that will be built. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent, priority. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI is higher.
The product backlog is property of the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team.
The sprint backlog is a greatly detailed document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice tasks are normally estimated between four and 16 hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills.
The sprint backlog is property of the Team. Estimations are set by the Team. Often an according Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
The burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.
It should not be confused with an earned value chart.
No comments:
Post a Comment