Hello Everyone
I put together an overall process guide on how to best use the Agile 2.0 application. Please keep in mind this is simply a guide not hard rules to live by. Additionally, the roles\personas, environments, and work ethic vary per organizational standard and culture.
______________________________________________________
Process Overview
______________________________________________________
Outlines the process flow for Agile Development from creating a product to the completion of development and releasing to production. The flow described here represents the common practice for creating and managing scrum records with the functionality provided in the base Agile Development.
______________________________________________________
SCRUM Process
______________________________________________________
The agile-scrum method for our architecture and software products. We deliver in sprints and maintain a constant dialogue between our developers and customer.
______________________________________________________
Roles In Scrum:
______________________________________________________
- Product Owner - is the sole person responsible for managing the Product Backlog. Is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list, deciding which should be at the top of the list for the next Sprint
- Development Team
- Is a collection of individuals working together to develop and deliver the requested and committed product increments.
- May include software engineers, architects, programmers, analysts, system admins, QA (Quality Assurance) experts, testers, UI\UX designers, etc.
- Builds the product that the Request Governance Owner indicates application. form process\workflow
- Includes all the expertise necessary to deliver the potentially shippable product each Sprint
- Is self-organizing, with a very high degree of autonomy and accountability.
- Decides how many items to build in a Sprint, and how best to accomplish that goal.
- Is a cross functional, small, and self-organizing team which owns the collective responsibility of developing, testing, and releasing the Product increment.
- May not appoint any team lead since decisions are taken collectively by the team.
- Scrum Master - promotes and supports the Scrum team and Scrum process
- Is a facilitator and Servant Leader who encourages and demands self-organization from the development team.
- Enables close cooperation across all roles and functions, addresses resource issue and disobedience of scrum practices.
- Protects the team from external and internal distractions.
- Removes impediments so the team can focus on the work at hand and follow scrum practices.
______________________________________________________
Scrum Events
______________________________________________________
Sprints
A sprint is the actual time period when the scrum team works together to finish an increment.
- Two weeks is a typical length for a sprint, though some teams find a week to be easier to scope or a month to be easier to deliver a valuable increment.
- The more complex the work and the more unknowns, the shorter the sprint should be.
- During this period, the scope can be re-negotiated between the product owner and the development team if necessary. This forms the crux of the empirical nature of scrum.
Sprint Planning
The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team.
- This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific use stories are then added to the sprint from the product backlog.
- These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.
Sprint Review
Is held at the end of each Sprint to review the achievements within that Sprint and adapt product backlog if needed.
At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team highlights the backlog items that are now ‘Done’ to stakeholders and teammates for feedback.
The product owner can decide whether to release the increment, although in most cases the increment is released.
Sprint Retrospective
The retrospective is where the team comes together to document and discuss what worked and what did not work in a sprint, a project, people or relationships, tools, or even for certain ceremonies.
The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time, and less about what went wrong.
Daily scrum or stand up
The goal of the daily scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours.
- This is a daily meeting that happens at the same time every day of the sprint.
- This meeting is also called a ‘daily stand-up’ emphasizing that it needs to be a quick one. The stand-up is the time to voice any concerns you have with meeting the sprint goal or any blockers.
A common way to conduct a stand up is for every team member to answers three questions in the context of achieving the sprint goal:
• What did I do yesterday?
• What do I plan to do today?
• Are there any obstacles?
______________________________________________________
Stories
______________________________________________________
The purpose of a story is to provide a high-level definition of a requirement, capturing the who, what, and why in a simple, concise way. A story should be small enough to be completed in one sprint. The estimated effort required to complete a story is measured in story points (see WIP limits), with more points being assigned to stories requiring more effort. Story points are arbitrary measurements of the effort (not necessarily the time) required to complete a story, based on the estimates of group members. The work required for a story can be broken down into discreet scrum tasks.
Story descriptions
A good user story description identifies the following for meeting the stated requirement:
- the role of the user persona in the system.
- the need expressed by the user persona.
- the benefit to all stakeholders such as developers, users, and others.
Typically, a story description is expressed as: "As a <role>, I want <goal or need>, so that <benefit>."
ROLE + GOAL\NEED + BENEFIT = STORY
Examples of good story description
- Description: As a developer, I want to publish the current state of my application to an update set, so that I can deploy it to a production system.
- Description: As a customer, I want to receive notifications when comments are entered for an incident so that I am updated on the status.
- Description: As a change manager, I want to enable the assessment of risk for any given change by establishing a list of questions with multiple choice answers.
Example of bad story description
Description: Notifications are sent when incidents are created.
This description is poor because:
- The description does not state who or what is sending the notifications, not in what form the notification takes, such as email.
- The description does not include any benefit information, so the business value is not clear.
It could be better written as:
Description: As an incident creator, I want email notifications to be sent to a predefined set of interested parties when I create an incident, so that they can be informed when an incident affecting them is created.
______________________________________________________
Story Acceptance Criteria
______________________________________________________
Acceptance criteria define the boundaries of a user story and are used to confirm when the software is working as intended, which means the story is completed. Acceptance criteria are an essential part of the 'Definition of Done' for a story.
Criteria
Should include the following, where relevant:
- Usability: Be sure to include measures of usability in the acceptance criteria. Indicate how to answer the question: Is it easy to use? The key is to identify the right measurements and make sure each is quantifiable.
- Functionality: Identify specific user tasks, business processes, or functions that must be in place at the end of the project. A functional requirement might be: The user can choose from multiple sizes.
- Error handling: Enumerate error cases and how each should be handled. For example, if a user performs the steps in the wrong order, how will the software handle it?
- Performance: Test system performance from the perspective of an individual user. For example: Is the UI (User Interfaces) responsive?
- Stress tests: Describe how the system responds when it is under stress because there are many users, transactions, or queries. Acceptance criteria should define acceptable thresholds for stress testing. For example: Does the system respond within a 250-millisecond threshold when 100 users submit queries simultaneously?
Have a Clear and Well-Defined Acceptance Criteria. After the product is developed it is necessary to have well-defined and clear acceptance criteria, since they are the ones which decide if the product is approved or not.
- Acceptance criteria should be testable.
- The acceptance criteria must be understandable to everyone.
- Criteria should be clear and simple.
- Acceptance criteria should provide user perspective.
Example of Good Acceptance Criteria
Description: As a customer, I want to order and pay for the book via a secure web-based form, so that my credit card information is safe.
Acceptance Criteria:
- All mandatory fields must be completed before a customer can submit a form.
- Information from the form is stored in the customer orders database.
- Payment can be made via Amex, Master Card, or Visa credit card.
- The system shall accurately calculate and apply sales tax.
- The system shall accurately calculate and apply shipping charges.
- The customer shall be able to verify the accuracy of the order.
- An acknowledgment email is sent to the customer submitting the form.
- Protection against spam is working.
Example of Bad Acceptance Criteria
Description: As a customer, I want to receive notifications when an incident is commented, so that I am updated on the status.
Acceptance Criteria: The appropriate people are notified when incidents are commented.
The acceptance criteria are poor because they do not give enough detail to test, for example, it is not clear who the appropriate people are. The acceptance criteria could be better written as:
- As an End User, create an incident.
- Select Notify interested parties.
- Save the incident.
- Log in as an interested party.
- Check that you have received an email for the logged incident.
______________________________________________________
Work In Progress Limits (WIP)
______________________________________________________
WIP stands for work in progress, and a WIP limit is a cap on the number of tasks your team is actively working on. It is a fixed constraint on a burn down chart that enables teams to finish the tasks already in the system before introducing more work.
Why do you need WIP limits?
When teams juggle between multiple tasks, they waste a lot of time, become inefficient, and don’t get a lot of work done. it takes time to get back to a task after being distracted. The WIP limits prevent exactly this. Some reasons to have WIP limits are Nothing is getting finished, You’re losing time and don’t know why, You have bottlenecks, Work is being duplicated or You want to be more efficient.
Determining WIP limits
You can determine the appropriate number of tasks in progress with story points to set those limits. You decide what the team can collectively handle as tasks at a time and implement a simple WIP limit for the Sprint as a whole. Usually doing your first sprint can give you a baseline of how much work can be inflight vs completed.
In some instances, it’s helpful to establish more targeted WIP limits; you may see that certain phases should only have 2 active tasks while others have the capacity for 3.
In rare cases, one team member may regularly be overwhelmed by tasks, so it could be beneficial to give her a personal WIP limit preventing Scrum Planning from sending more work than the individual can handle at any given time.
Personal WIP Limits can be applied at the column level if your Kanban board has rows that represent each person’s workload. They can also be applied with Avatars in a more team-oriented Kanban board. |
Team WIP Limits can be applied at the column level or across multiple columns. They can be combined with Personal WIP limits as well. |
______________________________________________________
Backlog
______________________________________________________
The backlog is a collection of debt seen as items to be addressed.
Product Backlog it is an ordered and prioritized list of everything that is known to be needed in the product. It is the sole source of requirements for any changes to be made to the product. It is never complete.
Sprint Backlog - it is the set of Product Backlog items selected for the Sprint.
Product owner
Defines a personalized backlog. Product owner has the privilege to define as many personalized backlogs, as necessary. The definition of the personalized backlog is flexible and can be modified at any time.
Sprint backlog
is a list of stories agreed to complete for a sprint. During sprint planning, the scrum master collaborates with the group to decide which stories they can commit to deliver in the sprint. Typically, they commit to the top ranked stories first. The group decides which scrum tasks are necessary for each story. The product owner should be present to answer any questions.
______________________________________________________
User Acceptance Testing
______________________________________________________
Create Detailed Test Cases
A test case specifies the work procedure, expected results and the conditions that a tester needs to verify. It is the basic documentation needed to determine if an application, or one of its features is working as originally planned and desired.
A step-by-step plan is needed. This will serve as a guide for people during testing. This way, they will be concentrated in the right places. it is necessary to include negative test cases to know what happens in case the user does something unexpected, and in this way not only the best-case scenario will be reviewed.
Challenges in User Acceptance Testing Process
New requirements from stakeholders
During the development of a product, stakeholders request changes whenever they want. They can even be changes requested at the last minute, which can hinder and delay the entire process. In these types of situations, it is necessary to make quick and timely decisions.
Untrained or improper UAT testers
It often happens that the people chosen to perform UAT are not aware of existing business needs. They can also face a lot of technical problems during the test run. That is why it is recommended to verify that all team members are well informed and that there are trained staff available to assist them in case questions arise during the Sprint Planning Sessions.
Limited time
UAT is performed at the last minute when there is little time for the product to go to production. It is a critical and vulnerable period, so there must be planning, well-defined test cases and a suitable test environment.
Ineffective communication
When communicating an error, there should be no ambiguity, everything that is communicated must be clear and simple, avoiding anything that interferes with the understanding of the situation. Clear communication should flow through the entire team.
______________________________________________________
Tying it all together in Agile 2.0
______________________________________________________
Products: Top tier of hierarchy. Have “Themes” which represent applications in ServiceNow
Epics: Represent a higher body of work or an initiative that tie multiple stories across multiple themes in order to track that effort
Sprints: Encompass the work accepted to achieve within 2-week increments. Contain a collection of stories to complete and can span products, themes and epics
Themes: Represent applications in ServiceNow that roll up to a product.
Stories: Represent the actual development task to complete that roll up to a theme, product and can be tagged to be part of an Epic
