2. Driving the future
of content
Apparatus
– 3 participants per group (BA, DEV, QA)
– Post-its, Pen or Pencil
– 1 dice per group
– Scissors (shared resource)
– 1 rupee coin
3. Driving the future
of content
– Follow the rules of the iterations
– The dice must be shaken at least 5 times before
you throw it
– Adhere to the timelines
– Don’t cheat and Have fun!
General Guidelines
4. Driving the future
of content
– BAs to roll the dice 10 times
– Each time create a post-it and add circles equal
to the number on the dice
– Each circle represents a story point
Create a Backlog
5. Driving the future
of content
– Each team runs a 3 day iteration (13 minutes)
– 1 min of sprint planning (commit stories)
– 2 min of day 1 execution
– 0.5 min of daily stand-up
– 2 min of day 2 execution
– 0.5 min of daily stand-up
– 2 min of day 3 execution
– 5 min of review and retrospective
Execution
6. Driving the future
of content
– Create pipes that can pass through the circle
drawn by the BA
– During the iteration:
– The DEV makes the pipes
– The QA checks for acceptance
– For every six rolled on the dice, BA adds a story
– Roll dice again for the story points (draw)
Objective
7. Driving the future
of content
– DEV can work on only one story at a time
– QA can accept only completed stories
– QA can create holes on the story card for testing
– In case of defect, send story back to DEV
Iteration 1 Rules
8. Driving the future
of content
– DEV can work on only one story at a time
– QA can accept partially completed stories
– QA can create holes on the story card for testing
– In case of defect, send story back to DEV
Iteration 2 Rules
9. Driving the future
of content
– BA to refine the story for coin sized circles
– QA can create a task post it to replicate acceptance
– QA can accept partially completed stories
– QA can create holes on the story card for testing
– In case of defect, send story back to DEV
Iteration 3 Rules
10. Driving the future
of content
– How can team agreements help? (e.g.: identifiers)
Learning
Intro, entertainer for the next 1.5 hours.
Software development cannot succeed without feedback. Customer feedback is late, testing is faster.
Any type of testing (traditional manual testing, automation, exploratory, usability) has 2 major stages – preparation and execution
Honestly the preparation stage doesn’t give any results; not to say it’s a waste but unless executed it’s worthless
One of the philosophies, not just in Kanban but other software development methodologies as well is to reduce waste
Now you can’t live without preparation but what you can do is reduce the amount of waiting time between the preparation and execution. This also includes reducing the dependency on programmers to start testing.
That’s what we will see in the next 1.5 hour.
Although what we’ll discuss will be more relevant to automation, but similar concepts can be applied to manual testing as well.
Also, my focus is going to be just one of the ways how test engagement can be improved and if you have done things differently that have worked for you please feel free to share this info as well.
Expectations:
1) Since partial stories are not being tested, testers will be idle for sometime
2) The audience can be asked how many face similar issue with manual or automation
3) Check velocity and retrospect how this can be improved
Expectations:
1) Although partial stories can be delivered initial tester idle time will still exist
2) Parallel tasks can be increased by devs delivering partial tasks and working on other stories. Although this involves switching constantly, improvement in resource utilization will be seen
3) Velocity must be accounted for only completed stories
4) Retrospect for improvements
Expectations:
1) Since the size of the circles are fixed, the testers can create holes at the same time when developers are creating the pipes. Test execution can be done as soon as the pipes are developed. Tester idle time reduced further.
2) Parallel tasks can be increased by devs delivering partial tasks and working on other stories. Although this involves switching constantly, improvement in resource utilization will be seen
3) Velocity must be accounted for only completed stories
4) Since the team has a defined identifier (rupee coin) tasks can be done in parallel and quicker