Showing posts with label Acceptance Criteria. Show all posts
Showing posts with label Acceptance Criteria. Show all posts

Wednesday 28 July 2021

Azure DevOps User Stories Tips

Quick Point on User Stories and Acceptance Criteria.

1.      User Stories description must follow the format:

As the <role> , I want to <feature> so that <benefit>

Note: Always follow the exact same format and bold up the standard/fixed parts for user stories.  Pls keep consistency across your teams user stories.  Under the user story in the description, feel free to add more description, annotated images (very useful) and links to Figma, Axure, UI mocks or Miro.  User Stories should also follow the INVEST (Independent, Negotiable, Valuable, Estimatable, Small, and Testable) breakdown.

2.      Acceptance Criteria (Use Gherkin Language) under the user story (ensure it goes into the User Story section and not comments or the description)

Scenario:
  Given
  When
  Then

Example

Scenario: Employee requests leave
  Given an employee has sufficient leave available in the year
  When the employee schedules leave (holiday)
  Then the employee is informed his request is valid and his manager is informed of the request.

Note: Always follow the exact same format and bold up the standard/fixed parts for user stories.  Pls keep consistency across your acceptance criteria.  I bold and use the four parts as shown above in the example.  You can use "and" to extend the story, just try keep them within the idea of INVEST.

3.      Other:  Order is Tasks belong to User Stories, User Stories belong to a Feature.  Features belong to Epics  These items must be related within Azure DevOps.   Epics > Features > User Stories (Acceptance criteria) > Tasks.

Scrum - Part 1
Scrum - Part 2 
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1

Azure DevOps - Introduction

Saturday 18 November 2017

TDD, BDD, DSL...

TDD - Test Driven Development is usual associated with Unit Tests.  

  1. Write tests before creating any application code.
  2. Write code
  3. Run code with tests to verify it works
  4. Repeat to add more functionality to your code

BDD - Behaviour-driven Development is an Agile development process that encourages collaboration between team members.   BDD combines TDD with ideas from domain-driven design (DDD) and object-oriented analysis and design to deliver software.   Get you requirements into User Stories, and develop Acceptance Criteria (I like Gherkin).  This ensure the "The Three Amigos" product owner/business, analysts, testers and programmers are on the same page (note these roles in Agile are often all performed by 1 person).

Domain Specific Language (DSL) - Language used to help communicate a systems behavior or share information such as User Stories and Gherkin,  DSL is very similar to a General Purpose Language such as Use Cases.

Monday 10 September 2012

Scrum for SharePoint - Part 2

See Part 1

Technology: I am using Team Foundation Server 2012 Release Candidate.  I believe the best tools for the scrum team are offered through Visual Studio. VS 2012 has all the features and VS2010 can't do specific tasks such as create projects however I've found using VS2010 to work well.  The template used in TFS is the Visual Studio Scrum 2.0 template.   Also see http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV212

Ways to work for TFS:  VS has the most comprehensive feature set for working with TFS 2012.  You can also use the TFS web UI, the SharePoint Foundation UI that is hooked up to TFS or excel and then import the data.


Creating PBI's: The screen shots use TFS2012 RC & VS2010.  I have annotated the screenshot to help with input of PBI's.  Not the priority is set from 1-1000 (default is 1000 which is the lowest priority).  I like to use Mike Cohan's planning poker (uses a relative Fibonacci sequence number to assign relative effort weight).  The scrum team vote on estimated effort after an understanding of the user story is complete.  Optional. Free tool to use for planning poker   Try this, a friend of mine built this while playing around for Scrum Poker Planning. 

The scrum master has to accept the PBI and for me to do this I need 3 pieces of information namely: the user story, acceptance criteria & additional detail short clear information such as an annotated Balsamiq mock-up.  Obviously the product owner  may negate the need for additional information but often they need to get this information from someone else in the business and I find mock-ups invaluable for clarifying to all people visual requirements.  Lastly, ensure that the team understand INVEST principles for  (Independent, Negotiable, Valuable, Estimat-able, Small, and Testable) for each User Story/Requirement.

Acceptance criteria is needed for each PBI.  This would be good to have in the Sprint planning meetings.  This is the format I recommend (gherkin language).
Scenario:
  Given
  When
  Then

An example I have is
Scenario: Employee requests leave
  Given an employee has sufficient leave available in the year
  When the employee schedules leave (holiday)
  Then the employee is informed his request is valid and his manager is informed of the request.

Acceptance Criteria – “What is Acceptance Criteria? Put simply, it's the criteria that defines what "Done" means for each PBI. Acceptance Criteria is critical to the success of a Scrum team, as it becomes the handshake between the Product Owner and the team -- it helps define what the team is committing to.”  http://www.nomad8.com/files/acceptance_criteria.php
"Pre-established standards or requirements a product or project must meet" Google's definition of acceptance criteria.
Normally acceptance criteria focuses on functional user stories but you also need to cover NFR's such as performance.  Negative acceptance criteria is often overlooked when creating AC's and do the AC's before development starts, you can always change them later.
An alternative to Gherkin for writing the acceptance criteria is to use checklists to ensure the User Story does what the business stakeholder wants and the developer has developed it correctly.

(Story Board)

The TFS 2012 Scrum template provides a good overview of the current sprint.  Team favorites are dropped from TFS queries to provide useful insights into the project.


Key Meetings:

1. Daily Stand-up (max 15 minutes):  I like to perform these at about 10:00 every day in the morning.  Each person tells the group: done/achieved in the past 24 hrs, what they are doing in the next 24 hours and brings up any blockers/obstacles/impediments.  I like to take notes as the scrum master and as the team falls into place.  I let team members run the daily stand-up scrum meeting in random turns once we all know how to do them and it seems to work well with communications in the team and I take summarized notes and I use the format:  Date, Time, Attendees, Each attendee summary & general meeting notes:  e.g. Adam and Paul were late for the meeting, blockers were not recorded, Kanban board was not updated....
Rules: Start at 10:00, be concise (part items that are taking to long and get the people to talk after the meeting), all participants to stick to the format: last day, today and blockers.  It always ends at 10:15 and leave the area.  Listen to the appoint meeting scrum master and they need to stop ongoing discussions.

2. Demo Meetings:  Date, time, attendees & roles, problems & suggestions.  Do at the end of sprint, tend to be 30 minutes to 90 minutes per demo each sprint. 

3. Sprint Review Meeting: Done at the end of a sprint cycle after the sprint is over.  Ensure each PBI is reviewed.  Often used with demos to validate each PBI and this allows the Product Owner to evaluate the PBI's fulfillment and make changes if necessary.  Important but can be skipped by the whole team as long as the PO does it and is happy.

4. Sprint Retrospective Meeting: Optional meeting to identify improvements that can be made.  I use this meeting after the Sprint Review at the end of the 1st 2 or 3 sprints and then only periodically as the project progresses.  Tip: Use the format: Glad, sad, bad game.  https://app.scatterspoke.com for managing Retrospectives.  An alternative is to the approach: What went well, What didn't and What needs to happen.


I've seen many different formats for running retrospectives, and a good default option for me is "mad, glad, sad". I also like the Danish baking Retrospective that I saw recently.  
Azure Devops Danish Baking Retrospective Board

A nice feature I was shown recently was to "Include a Team Assessment".  I'd use it every 3-4 sprints assuming we are using 2 week sprints, the results are a great indicator of confidence and the teams position.
Team Assessment in DevOps Retro board 

5. Sprint Planning Meeting:  Have a sprint goal.  Done at the start of the sprint cycle.  The scrum team and the product owner identify items from the product backlog to go into the sprint.  The last part of the meeting is to create a sprint backlog to implement each item selected from the product backlog.  I also like to have a grooming of stories in the previous sprint to ensure the whole team know what is likely to come along and tech can feedback to the PO/stakeholders.

Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2 (This Post)
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1