Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

ISCG7427 - Topic 3 - Agile Practices

Agile Practices
by

Alan Kan

on 28 November 2018

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of ISCG7427 - Topic 3 - Agile Practices



User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. (Mike Cohn)
Defer details and capture them through
discussion
just in time for development
Captured by team members, product owners, scrum masters and users
Usually in the format of Role-Feature-Reason

As a
[role]
I want to
[feature]
so that I can
[reason]









Why User Stories?
Useful for planning work
Focus on delivering value to stakeholders
Eliminate waste effort by just-in-time elaboration
Vehicle to add features in iterative development
ISCG7427
Agile and Lean Software Delivery
Topic 3 - Agile Practices

Project Initiation
Develop a shared vision

Planning and Features
Creating User Stories
Backlog Grooming
Release and Iteration Planning
Prioritise User Stories
Estimate in Story Points
Scheduling
Visualisation
Burndown tracking
Daily Scrum Meeting

Construction
Iterations
Sustainable pace
Architectural Spike
Model Storming
Test Driven Development
Pair Programming
Refactoring
Continuous Integration

Delivering
Continuous Delivery
Demonstrations
Retrospective

How large should a story be?

A Story should fit into one sprint of work. A story too big to complete in one iteration is called an Epic. An Epic will be broken down into a few stories.

Some tips to breaking complex stories:
If the story describes a workflow, take a thin slice of the workflow and enhance later
If the story describes multiple operations, break them down by operations
If the story has a main scenario and sub-scenarios, break them down by scenarios
If the story has a complex UI, start with a simple UI story, and enhance later
If the story refers to multiple users doing the same thing, cater for one user first, and add more users later
If the story is complex because of NFR, break off NFR from functional requirements
If the story has a major effort no matter how it is split - split it so that most value comes from the first split
If the story has a lot of dependencies and a variety of business logic, do a subset first and enhance later
If the story requires some serious research, break the research task into another story
Developing a Shared Vision

A shared vision inspires people and gets them to pull together for cooperative action.
People become energized by what their group is trying to accomplish.
People can see a personal role in bringing the vision to life. This is the "shared" aspect of a shared vision.

Good visions:
Provide inspiration to the team
Are written so that the mission is easily understood
Reflect both individual and organisational needs
Are concise
Are accessible to all stakeholders
List key features that help justify investment in project

Initial agreement of the vision should occur during the working sessions with the key stakeholders

A Vision Statement should include:
Target customer/user/beneficiaries
The customer needs that is addressed by this project/product
Key product attributes
How the product is different from competition
Target timeframe and budget

A Vision Statement "document" may optionally include:
List of key stakeholders
Goals of the key stakeholders
Business process model
Governance strategy for the project
Executive summary
List of constraints, both business and technical
An indication as to the feasibility of the project

After that the Product Owner will:
Develop the initial stack of user stories (will become Product backlog)
Gather enough information to address initial scheduling and estimating concerns





What about non-functional requirements such as speed and availability?

Technical stories are one way to capture non-functional requirements (NFRs). For example:
The system will conform to corporate user interface guidelines
The system will follow corporate security access guidelines
Financial transactions will run within 2.4 seconds 99.7% of the time

NFRs are:
Cross-cutting
Pertinent to many functional requirements (user stories)
Typically maintained outside of the work item list
Addressed throughout the entire project
Often technical constraints on your solution

NFRs drive:
The development of acceptance or system tests, which validate that your solution conforms to those requirements
The development of architectural aspects
The definition of what it means to be done at the end of an iteration

User Story Exercise

Time allowed: 5 minutes

The goal of this exercise is to write 10 user stories for the university course planner mobile app v3.0

Do the following:
Get back together in your groups from the last exercise
Tasks:
Each person in the group will pick a role from the stakeholders (e.g. Student, Professor, Course Administrator, etc) and write user stories on sticky notes from that stakeholder's perspective (one story on each note)
Focus on the user story headline; other information will be captured later
Important:
Save these user stories for future exercises
Although the focus is on user stories, you might identify a few technical stories as well
Try to work through several scenarios to identify the potential scope of the system

Case Study for Class Exercises

You work for a university's IT Department.
Your team is responsible for developing the next release of a Student Course Planner application
History of prior releases:
Version 1.0 was a Student Course Search mobile application that students can search a course by course number and by keyword. The application then displays course details such as title, descriptions and pre-requisites.
Version 2.0 of the mobile application allowed students to create a plan for a 3-year programme by adding courses to a plan after searching for the course. The plan cannot be saved. But it can be printed out for future reference.

The scope of Version 3.0 is not yet set. You are going to set the initial vision of Version 3.0. After talking to stakeholders you know that:
the University recently partnered with IBM to allow students to gain work experience at the IBM Delivery Centre while they study.
There are plans about students earning some credits towards their course by working at the IBM Delivery Centre instead of classroom study.
The longer term strategy is to enable the University to also partner with other industry organisations beyond IBM to provide students with more opportunity to gain work experience.

It’s up to your team to define the direction for version 3.0 of the mobile application, but your plan will have to be approved by the university's Executive Board (your course instructor).
Exercise - Setting up Team and Vision

Time allowed: 10 minutes

Form groups of up to four people
Try to work with people whom you don’t normally work with
Try to form a cross-functional team as best as possible

The goal of this exercise is to perform the initial work for a shared vision of the project. In your groups discuss the following:
Who are the key stakeholders of this project?
For each stakeholder, what do they want out of the project (what are their goals)?
What are the conflicts that might arise due to different stakeholder goals?

Normally you would interview the stakeholders to identify their goals, but in this exercise you will brainstorm as a team

Discuss as a class (led by instructor):
who are the stakeholders and what they want
What is the common objective / vision of the application?


Planning Poker

The Scrum Master facilitates this session
Iteratively:
Each team member is given a deck of cards, each card has a valid estimate written on it
Pick a story (or requirement or feature) to estimate
Customer/Product Owner reads the story, and the team discuss the story until it is understood
Each team member selects a card that's his/her estimate
Everyone shows their cards
If the team agrees, record the story point and pick the next story to estimate
If the team does not agree, the members with the highest and lowest estimate explain why they estimated that way
Re-estimate until agreement

A
burndown

chart
is a graph that shows the remaining units to complete that is measurable and will eventually become zero

Typically Scrum Master keeps track of the points completed and remaining in each iteration, and plot them in charts and put up on a whiteboard

Iteration burndown – estimated effort hours remaining in the iteration
Release burndown – estimated functionality yet to be built for the release
Product burndown – estimated functionality yet to be built spanning multiple releases


Architecture Spikes

Sometimes team members will work with a technology that they are not familiar with.

You must gain experience with that technology
Make informed decisions regarding its application.
Tradeoffs are inevitable.
Some use patterns are effective; some are not.
The technology might not work well in your environment for a variety of technical and cultural reasons.

Perform an architectural “spike”:
Write just enough code to explore the technology.
This short bit of code is typically thrown away.
Typically dedicate hours or days of effort to this code, not longer.

Consider “bake offs”
If you’re considering several competing technical options, you can spike them all in parallel

Pair Programming

The concept comes from Extreme Programming (XP). Two or more developers work on the same piece of code
together
- typically one watching over the shoulder of the other for a period of time, and then switch

Benefits
Enhanced quality: The pair or group checks the artifact for quality.
Reduced cost of development: Inconsistencies and bugs are caught early in the cycle.
Knowledge sharing: Domain knowledge and development techniques are shared among individuals (pair or group).

Potential barriers to adoption
Some people might not be comfortable or feel intimidated working in pairs.
Some cultural aspects and personal habits can be obstacles to pairing.

Refactoring

Refactoring is a simple change to your source that improves the design without changing its semantics.

By refactoring, you can evolve your development assets in a controlled manner, maintain the high quality of your design.

Types of refactoring:
Code Refactoring
- A small change to your code to improve your design that retains the behavioural semantics of your code.
Examples: Rename a method, move a method, and remove a setting method

Database Refactoring
- A simple change to a database schema that improves its design while retaining both its behavioural and informational semantics
Examples: Move a column, rename a table, and replace a blob with a table

User Interface Refactoring
- A simple change to the user interface that improves the design without changing the semantics of the function that is provided to the user.
Examples: Align widgets, standardise formats, move a widget, and replace a widget
Model Storming

Just-in-time (JIT) modeling
The “conversation” for a user story occurs on a JIT basis.
Several people meet.
They use a simple modeling tool (a whiteboard, paper and pencil), and gather the details as needed.

Model storming is common
For requirement analysis by using UI sketching or storyboarding techniques
For architecture and design by sketching a quick sequence diagram or class diagram, or creating some CRC cards

Typically takes 15-60 minutes
Sustainable Pace

A sustainable pace is the rate of work that a team can consistently maintain without burning out team members.

Popularised by the extreme programming (XP) methodology

The “40-hour work week” practice

Brief spurts of overtime are acceptable, but can’t be sustained indefinitely. Recognise sustained overtime as a failure.

Strategies:
Acknowledge that you're still working productively at a sustainable pace.
Organise the project into short iterations.
Avoid mini-waterfalls.
Adopt a continuous integration strategy.
Collaborate frequently with team members.
Continuous Integration

In software development, continuous integration (CI) is the practice of merging all developer working copies with a shared mainline several times a day.

It was first named and proposed as part of Extreme Programming (XP).

The practice involves team members integrate their work frequently, usually each person integrates at least daily leading to multiple integrations per day.
Version control repository and continuous build tools
are used for integrating the code and build, and then automated tests are run to get immediate feedback on integration problems.

The key benefit of CI is to identify integration problems early and address them before they build up to more complex problems, or Integration Hell as described by XP.


Test Driven Development
Add a Test
Run all Tests
The newly added test should fail because no code has been written to fulfill the feature yet. This gives you some confidence that the test is working.
Write More Code
Write just enough code to pass all the failed tests. It is ok if the code is not elegant at this stage.
Run All Tests Again
To Test your new code. Note that this also tests whether your new code breaks old functionalities. If the tests failed, write code to pass it.
Refactor Code
The code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use, etc. Apply your usual "good programming practice".
To start developing new functionality, write a test for the new functionality and then add the test to the list of existing tests. To write a test, the developer must clearly understand the feature's specification and requirements. They come from User Stories and related discussions
Test Driven Development (TDD) is the practice of developing a functionality by writing unit tests before the code is written. By default, it requires tests to be automated.
Daily Standup Meeting (Also called Daily Scrum Meeting in Scrum)

This is a short status update meeting that occurs daily

Each team member answers three basic questions:
What did I do yesterday (or since the last meeting)?
What will I do today (or until the next meeting)?
What is blocking my progress?

Scrum Master's role is to makes sure that the meeting occurs. Scrum Master usually facilitate the meeting but team member should be able to meet without Scrum Master after a few Sprints.

The team meets every day, at the same place and time to avoid overhead and complexity
Start meeting on time
Keep the meeting under 15 minutes
Everyone gets a chance to speak
Takes notes of a list of issues that might need follow up after the meeting, and who the issue is assigned to.
No blaming
No detailed status report
Not a platform to re-prioritise user stories
Do not resolve issue within the meeting
Team members report to the team, not to the Scrum Master. Scrum Master does not assume a position of power. Scrum Master ensure the team is in charge
Visualisation

A Taskboard shows tasks in columns by status, and how User Stories relate to their tasks.

Teams will decide how best to name the columns. It provides a at-a-glance status for a project.

A manual taskboard is usually placed at a highly visible place for everyone to see.

Tasks are usually represented using a post-it notes. When a task changes its status (e.g. from "to-do" to "in progress"), the post-it notes will be physically moved to the next column by the member who did the work.



Electronic task boards are available. These are some industry tools:
IBM Rational Team Concert
IBM Bluemix DevOps Services
Redmine
RallyDev

Advantages of electronic taskboards are:
Suits graphically distributed teams and complex projects that needs huge physical whiteboard
More eligible writing
Audit trail of changes
Easy to run analysis
Automation
Traceability

Iteration (Sprint) Planning Meeting

Performed together by team members, Scrum Master, and Product Owner at the beginning of each Iteration (Sprint). The key purpose of the meeting is to decide what backlog items will be tackled in the upcoming iteration.

Two main outputs from iteration planning meeting:
1. Goal for the coming Iteration (Sprint) - one or two sentence to describe what the team wants to achieve in this iteration.
e.g. "Develop shopping cart features that includes add, update, delete item from cart and display cart"
e.g. "Setup infrastructure in order to develop User Stories"

2. Iteration(Sprint) Backlog - a set of product backlog items that the team has committed to delivering in the next iteration, plus the tasks needed to deliver the items. It usually includes estimates for the tasks and team members would have signed up for the stories/tasks.
Demonstrations

At the end of an iteration, the team demonstrates the solution, or allow stakeholders to actually use the solution, and invite feedback

Show completed work only. Work in progress are not demonstrated

Capture new work items (new story, defects) that feedback generates and add to product backlog
Retrospective

Review the effectiveness of the development process and environment:

See this website dedicated to retrospectives: www.retrospectives.com.

Ask:
What went well?
What could be changed to deliver better results?
What have we learned?
What still puzzles us?

Capture lessons learned:
Target the top three issues.
Do not take on too much.
If needed, add actions to backlog of tasks

Next iteration:
Take 1 or 2 concrete actions:
For example, “We need to stop doing X.” “We need to get better at Y.”
Invest the appropriate amount of time versus value to be gained.

Common Issues:
A story is not completed - the entire story point goes to the next sprint
We planned to do X points, we only did Y points - see what can be improved
We missed some tasks at planning - add the tasks back when you realised you missed them. Find a way to make sure you won't miss them next time.
During the iteration we realised we missed a user story, which another stories depend on - identify the new story, prioritise it, estimate it, and include the story in the backlog.
Stub out the missing functionality, or swap the blocked requirement for something else.
Learn from this experience and improve your requirements exploration efforts.
Continuous Delivery

Continuous Integration usually refers to integrating, building, and testing code within the development environment. In contrast, Continuous Delivery builds on this, dealing with the final stages for production deployment.

Continuous Delivery refers to the practice of creating software so that they can be deployed to production environment at any time. Typically this will need to be achieved by:
- Having continuous integration practice, so that the application executable is always in a deployable form
- Using an automated deployment tool (e.g. IBM UrbanCode Deploy) to promote application through increasingly production-like environments
- Having automated testing practices so that defects can be detected

Why Deliver Frequently
- Discover integration problems sooner
- Get earlier feedback from business
- Respond to change more quickly
- Realise benefits earlier
- Save time from debugging

Continuous Deployment
Continuous Delivery is not to be confused with Continuous Deployment. Continuous Deployment refers to the practice of automatically deploying integrated and tested software application into production. Continuous Delivery refers to the ability to deploy applications continuously, but do not actually deploy into production. There are reasons for an organisation to not automating deployment into production.

Challenges and Costs to Deploying Frequently
- Require a lot of discipline and automated tools
- Users do not like an application to change frequently
- Need to maintain automated tests to keep up with changes
- Need to make sure the right approval is in place
As a
customer
I want to
withdraw money
so that
I can spend it
As a
student
I want to
enroll in a course
so that
I can complete my degree
As a
visitor
I want to
search for a product
so that
I can buy it
User Stories
AS a registered jobseeker, I WANT TO create and edit my CV SO THAT employers and recruiters can view my career summary and contact details

Backlog Grooming (also called Backlog Refinement or Story Time)

Backlog Grooming is the act of adding detail, estimates and order to items in the Product Backlog. If this is not done at a Backlog Grooming meeting, the tasks will be done in a sprint planning meeting

Ongoing process conducted by the collaboration of the Product Owner and team members
Help make Sprint Planning Meeting more efficient and enhance quality through better understanding
Grooming usually time-boxed to 5% - 10% of the Development Team’s capacity
Typically 3 days before Sprint Planning Meeting and on a weekly basis
Development Team is responsible for all estimates. Product Owner supports team by helping understand items and select trade-offs
How grooming is performed is determined by the Scrum Team
Ideally discuss 2 sprints worth of backlog items

Three common ways to add details:
1. Create graphics and/or text to describe a user story
2. Break up a complex user story into a few simple user stories
3. Identify Acceptance Criteria for a user story.



When do you know a story is completed?

You need an
Acceptance

Criteria
for each story. An Acceptance Criteria defines how you test for completion of a story. It helps:

1. Define the boundary of the story - all the tests needed to ensure the story is completed

2. Enable time estimations - you need to know the end status of a task in order to perform estimates

3. Avoid misunderstandings - a common understanding of the definition of done help avoid misunderstandings and disagreements.

4. Assure quality - the Acceptance Criteria is the foundation of acceptance tests. It defines quality and helps avoid technical debt by including test cases, refactoring, code documentation, and so on.

5. Helps shifting stories to the Done column - with no clearly defined acceptance criteria and definition of done, it's easy to end up with the five more minutes syndrome, and gold plating.

Agile teams also talk about the
Definition of Done
. The Definition of Done is often referred to how we define a story as being Done. Some team define it as
Done Done Done
. DDD means a story has passed 3 stages and ready to deploy into production:
Coded
- software code written
Verified
- software code tested against Acceptance Criteria
Validated
- Product Owner confirmed that the feature provides value to stakeholders
Some example acceptance criteria:

The user must sign into a registered account to create a CV

The user cannot save a CV unless it has a jobseeker name, address, and summary.

The user should be able to edit and delete contents in the CV

Data from the saved content is stored in the CV database

Only registered Recruiters and Employers can view the users CV and contact details
Planning
Source: http://www.mountaingoatsoftware.com/uploads/presentations/Planning-Tracking-Agile-Projects-Agile-2007.pdf, reproduced with permission of Mountain Goat Software
Strategy
– Strategic vision is at the top of the planning onion because it defines a what a company is and what it wants to become.
Portfolio
– The portfolio layer of the onion represents the overall product offering that consists of application suites and tools and how they interact with each other.
Product
– The product layer represents the set of product features for one or more related products (product suite).
Release
– Represents a subset of the prioritised backlog of product features that is a smaller plan (a release) that drive toward the product vision.
Iteration
– An iteration is a subset of features (stories) that we plan to deliver in time-boxed increments.
Day
– The day layer of the planning onion is best described by the actions we take in one day toward the iteration story goals
Business Planning
Agile Planning
Release planning

Release planning means making a prediction of either:
1. what would be delivered at a release date
2. how long it takes to deliver a set of features

You need:
1. The velocity at which the team delivers
2. The length of the project
3. The prioritised product backlog

Prioritising User Stories
Prioritisation is performed by the product owner, who balances the needs of all stakeholders, not just users. Team members can suggest priorities but must be able to explain the reasoning and trade-offs involved

Prioritisation is done at these times:
1. when creating the initial user stories / features that define initial scope of the backlog
2. sprint planning meeting
3. any time required by stakeholders (decided by product owner)


Discussion: What approach would you take to prioritise if you find yourself having 8 assignments due next week, and you only have time for 5 of them?



2 approaches:
1. A value-driven approach (core approach)
Assign in-scope high-level requirements across all Sprints in priority order by business value

2. A risk-value driven approach (disciplined approach)
Assign high-risk items, particularly architecturally significant requirements, to early iterations
Assign remaining in-scope high-level requirements across all iterations in priority order by business value

Prioritised user stories / features will be added to product backlog. The product backlog will also contain technical tasks, defects to be fixed, and knowledge acquisitions tasks.
Estimate
Performed by the whole team but lead by the Scrum Master

Story Points
Story points come from Extreme Programming (XP) to measure the high level effort of each story.

Story points are based on a both the size and complexity of the work, and are subjective for each team

The team will need to calibre points at the beginning of a project to agree the standard

To use story points, the team reviews each story (or requirement or feature) that is being considered and assigns it a size based on an agreed-upon standard. Two usual standards:
Easy = 1, Medium = 3, Hard = 5
Fibonacci sequence – 1, 2, 3, 5, 8, 13, 20, infinite or unknown
Release Planning is performed by the whole team together

To estimate project duration In the first iteration:
Choose an iteration length (e.g. 2 weeks, 4 weeks, etc)
Estimate your
velocity
, the number of points you think you can deliver each iteration
Total number of points / velocity = number of iterations needed.
Number of iterations * duration length = total estimated development duration
You still need to schedule time for project initiation and deployment
Velocity only include COMPLETE stories. Do not include points from incomplete story. e.g. if you completed 38 points in a sprint, and half of a 4 point story, your velocity is 38 points.

Over time:
After 3-6 iterations, your project
velocity
, the actual number of points completed in the last few iterations, should be substantially more stable. Scrum Master should track the number of completed story points for each iteration in a
Burndown Chart
You can use the actual velocity to estimate
Do 2 estimates - one with low velocity and one with high velocity (see examples)
Scheduling
Reproduced with permission of Mountain Goat Software
Source: http://www.mountaingoatsoftware.com/
Estimate features from Fixed Date

Desired Release Date = 30 September
Start Date = 1 April
Sprint duration = 1 month
Number of Sprints = 6
Lower Velocity = 20
High Velocity = 25
20 x 6
25 x 6
Will do
May do
Won't do
Estimate duration from Fixed Scope

Total story points desired = 200
Lower Velocity = 20
High Velocity = 25
200 / 20 =
10 iterations


200 / 25 =
8 iterations
Break into Tasks and Effort Estimate
Based on a prioritised and estimated product backlog, individual team members break user stories into tasks. They also sign up to the product backlog items for the next iteration. These items form the Sprint backlog.

The team break their own user story down into tasks required to complete them. For example:
Discuss story
Mock User Interface
Code the User Interface
Code middleware layer
Write unit test
Automate tests
Bug fix
Demonstrate story
Write end user documentation

The tasks are then estimated in time units (minutes, hours, days, weeks). e.g. Discuss story - 15 mins
Bill Wake's Invest model to write user stories

Independent
Negotiable
Valuable
Estimateable
Small
Testable

Iterations and Pace
Iterations and Incremental Development

An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas. The team then iteratively refines those areas until the product is satisfactory. With each iteration, the software is improved through the addition of greater detail.

An incremental process is one in which software is built and delivered in pieces. Each piece, or increment, represents a complete subset of functionality. The increment may be either small or large, perhaps ranging from just a system’s login screen on the small end, to a highly flexible set of data management screens.
Agile Design Practices
Continuous Integration and Delivery
Exercise - Delayed Integration
Time allowed: 30 minutes

Work in a group of 5.
Divide the group into 2 pairs of 2, plus a person to time the exercise

Each pair writes 15 random words on a piece of paper independently. Neither pair gets to see the other pair's work in progress. When both pairs are finished, reveal the list to the group, try to make 3 logical sentences using all 30 words.

If the group can't make complete sentences that uses up all words, go back into pairs and modify the word list (add or remove any words, but keep to 15 words). When both pairs are finished modifying their list, reveal the lists and try to make the sentences again. Repeat this process until you have created sentences that uses all 30 words.

Timer records the total duration, and any "wait time" when one pair has completed and the other is waiting.

Exercise - Continuous Integration
Stay in your group of 5. Another person can be the timer.

Each pair writes 5 random words on a piece of paper.
Neither pair gets to see the other pair's work in progress
When both pairs are finished, reveal the list to the group. The group should only have 10 words in total. The group then discusses what to change/add to the lists in order to make 3 logical sentences using 30 words.

Go back into pairs and modify and/or add to the word list until each pair has 15 words. When both pairs are finished modifying their list, reveal the lists and try to make the sentences again. Repeat this process of modifying word list (keep to 15 words per pair) until you have created 3 sentences that uses all 30 words.

Timer records the total duration, and any "wait time" when one pair has completed and the other is waiting.
Class Discussion: which way is faster? Easier? Why? What does it tell you about early integration of work?
Adding Story Details Exercise
Time allowed: 5 minutes

The goal of this exercise is to break up complex user stories into simpler ones, and add acceptance criteria.

Step 1. In your team, discuss how you can break this epic into multiple stories:










Step 2. Define acceptance criteria for the user stories (there should be multiple acceptance criteria in order to fully define the story)

Instructor will lead discussion on breaking the epic and defining acceptance criteria
Exercise - Visualisation, Daily Scrum and TDD
Demonstration Exercise
Time allowed: 10 minutes (each group presents for 5 minutes)

Goal of this exercise is to simulate Sprint Review

Pair up your group with another group. Show the wireframe(s) that your group has drawn to the other group, one or more of the group members will explain to the other group:
1. the user story
2. how your wireframe meets the acceptance criteria
3. The audience can provide feedback on:
a. whether acceptance criteria have been met
b. what are some potential improvements
4. a member in the presenting group will write "defects" and potential improvements on sticky notes, and add to the to-do column on your task board (if still available)
Exercise:
try drawing the
burndown chat for the following
progress:
I1 = 100 pts committed
I2 = 20pts done
I3 = 30pts done, 5 pts new
I4 = 20pts done, 15 pts new
I5 = 20pts done, 5 pts new
I6 = 25pts done
I7 = 10pts done
T Shirt Sizing

An alternative way of sizing user stories is to classify them into a scale of Extra Extra Large (XXL), Extra Large (XL), Large (L), Medium (M), Small (S), and Extra Small (XS).

The team writes down these t-shirt sizes on a piece of paper as column headings, and then the team can discuss each user story and agree what size the story should be, and then place the story cards (or sticky notes) under the agreed size heading.

When all story cards for the iteration are estimated, the team can then assign story points for each "size". e.g. 1 point for XS, 2 points for S, 3 points for M, 5 points for L, 8 points for XL and 13 points for XXL. These story points then can be transferred to the corresponding user stories.
Pick what suits your team!!
Source: http://www.mountaingoatsoftware.com/system/asset/file/259/User-Stories-Applied-Mike-Cohn.pdf, reproduced with permission from Mountain Goat Software.
(source: http://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental, reproduced with permission from Mountain Goat Software)
Source: http://img151.imagevenue.com/img.php?image=28385_messefeatures_122_458lo.jpg. Reproduced with permission from Craig Larman
Tell me (at least) one idea you learnt in this topic

How can you apply what you learnt outside of the class?

Is there anything you are not clear on this topic?

Is there anything we did in this topic that you would like changed?
Retrospective
Source: http://www.mountaingoatsoftware.com/agile/scrum/product-backlog/, reproduced with permission from Mountain Goat Software.
Source: http://www-01.ibm.com/support/knowledgecenter/api/content/nl/en-us/SSCLKU_7.5.5/com.ibm.xtools.tutorial.bpmn.diagram/images/BPMN_gates.gif
Reproduced with permission from Craig Larman.
Vision Statement

FOR
the students in this class

WHO
want to learn more about Agile

THE
ISCG7427 paper

IS AN
Agile course

THAT
will help us get a better appreciation and prepare us to work within an Agile Environment

UNLIKE
other courses, our paper will teach Agile by letting you experience Agile
"As a student, I want to manage 'IBM work experience' in my plan so that I can add, update, delete work experience in my plan
Exercise - Estimation

Time allowed: 10 minutes

The goal of this exercise is to practice sizing estimates for user stories via planning poker.

Get into groups of 4 or 5. We will continue to use the university course planner mobile app case study. For the following user stories, your group will need to:
Choose an estimate point scale (for example, 1, 2, 3, 5, 8, 13, 20 or t-shirt sizes)
Agree on a medium-sized story, and assign it a medium-sized value (for example, 5)
Pick another user story, each member in the group will individually write down an estimate, and then reveal it together as a group
For any discrepancy between group member's ratings for the same user story, the disagreed members should tell other members the reasons for the ratings
Agree on a final rating (not via voting, but via talking through reasons and agreeing)
Move to estimate the next user story until you complete estimates for all 4 user stories

As a student, I want to add IBM work experience that to my plan, so that I can get credit for the work experience
As a lecturer, I want to view a list of all students enrolled in IBM work experience in the coming semester
As an IBM executive, I want to perform analytics on class data so that I can understand the effectiveness of the partnership
As a student, I want to see an error message if I entered a paper number that does not exist, so that I will enter the right information
Exercise - Break Stories in Tasks and Estimate
As a student, I want to add IBM work experience to my plan so that I can get credit for work experience.

Acceptance criteria:
From the View Plan screen, there is a way to let student to choose to add work experience
Student can select a work experience course to add
After clicking the Add button, the work experience appear in the student’s plan on the View Plan screen
Time allowed: 15 minutes

The goal of this exericse is to simulate sprint planning

Get into groups of 4 or 5. We will continue to use the university course planner mobile app case study.

You are given the high priority user stories in the backlog (see bottom of the screen). In a later exercise, you will draw the wireframe screen designs for these user stories to simulate implementation. For this exercise, your group needs to:
Break all user stories down into tasks and write these tasks onto sticky notes. Typical tasks include “create design drawing”, “write test case”.
Estimate time it takes to complete each task, write the estimate on the corresponding sticky-notes with the tasks.
Examine task dependencies – is there any tasks that need to be completed before another task can be started?
As a group, decide which (one or more) user stories your group will be able to complete in 9 minutes. "Complete" means having all tasks done for a user story, including testing your design drawing against acceptance criteria
As a student, I want to view IBM work experience that I added to my plan, so that I can manage my plan

Acceptance criteria:
There is a View Plan screen that shows a list of courses selected for a logged in student
By default, the View Plan screen lists courses by “semester” and “year”

As a student, I want to delete IBM work experience that I added to my plan, so that I can change my mind

Acceptance criteria:
From the View Plan screen, there is a way to let student to remove work experience already added to the plan
If the plan does not have a work experience added, there is no ‘remove button’
Once the user choose to remove work experience, the work experience no longer shows in a plan

As a lecturer, I want to view a list of all students enrolled in IBM work experience in the coming semester.

Acceptance criteria:
After a lecturer is logged in, he/she can select to view a list of all students enrolled in IBM work experience
If not logged in as lecturer, there is no option to view list of all students
After lecturer choose to see list of students, the lecturer can choose the semester and year, and then the View Students screen shows a list of students enrolled in IBM work experience for the semester and year
Exercise - Setting up a Task Board
Time allowed: 3 minutes.

Goal of the exercise is to setup a taskboard for visualisation

Get back to your groups. If your group has not created 4 sticky-notes for the 4 user stories in the previous exercise (screen 30), do it now.

Draw 5 columns on a whiteboard with these headings - Story, To-do, In-Progress, Testing, Done

Take your 4 User Stories sticky notes and put on the story column

Take your Tasks sticky notes and put on the To-Do column, next to its corresponding stories

Take a photo of your task board (using your mobile phone)
As a student, I want to add IBM work experience to my plan so that I can get credit for work experience.

Acceptance criteria:
From the View Plan screen, there is a way to let student to choose to add work experience
Student can select a work experience course to add
After clicking the Add button, the work experience appear in the student’s plan on the View Plan screen
Time allowed: 30 minutes

The goal of this exercise is to simulate sprint execution

Preparation work (5 minutes):
Get back to your groups from last exercise. Your backlog includes the 4 user stories below. For each user story, you have 3 tasks: write test instruction, create design wireframe, and test the design wireframe (against test instruction). Create sticky notes for each user story and their tasks, and stick them on an information radiator (whiteboard with columns and headings)

Simulation (20 minutes):
Each 4-minute interval represents one day. And we will simulate 5 days.

Start each iteration with a 1-minute (or less) Scrum meeting. In this meeting, you need to move "task" sticky notes to the correct column to reflect task progress, as well as agreeing task ownership for the next 3 minutes.

Then the group will work on the tasks for 3 minutes (some members could be writing test, some could be creating design wireframe, some could be testing the design following test instructions).

Repeat 4 times the process of 1-minute Scrum Meeting and task agreement, and work on tasks for 3 minutes.

Instructor-led discussion -
does it get easier over time? Why?
did your group complete all user stories committed?
As a student, I want to view IBM work experience that I added to my plan, so that I can manage my plan

Acceptance criteria:
There is a View Plan screen that shows a list of courses selected for a logged in student
By default, the View Plan screen lists courses by “semester” and “year”

As a student, I want to delete IBM work experience that I added to my plan, so that I can change my mind

Acceptance criteria:
From the View Plan screen, there is a way to let student to remove work experience already added to the plan
If the plan does not have a work experience added, there is no ‘remove button’
Once the user choose to remove work experience, the work experience no longer shows in a plan

As a lecturer, I want to view a list of all students enrolled in IBM work experience in the coming semester.

Acceptance criteria:
After a lecturer is logged in, he/she can select to view a list of all students enrolled in IBM work experience
If not logged in as lecturer, there is no option to view list of all students
After lecturer choose to see list of students, the lecturer can choose the semester and year, and then the View Students screen shows a list of students enrolled in IBM work experience for the semester and year
Full transcript