In agile model, Dev engineers and QA engineers work on a story and deliver it at the end of the sprint. Touch time can be defined as the "The actual time spent developing a product or service with the ultimate goal being the addition of value to the end consumer". Let me take the following imaginary scenario to explain this concept.
A dev engineer completed the development of the story in 1 hour on Monday. QA engineer needed to start verifying it on Tuesday morning, but as QA engineer is already busy with another story, he couldn't pick it up. QA engineer verified that story on Wednesday in an hour and logged a critical defect. Dev engineer couldn't pick that defect immediately and he fixed it on Thursday in 1 hour. QA engineer picks it on Friday and closed the story. In this example, actual time spent on this story is 4 hours and story marked as completed in 40 hrs. Here the Touch time is 10%.
Why do we do multitasking
As part of resource utilization, we want to do something instead of waiting for a task to become unblocked. That exactly happened in above example. If the team multi-tasked to fill the waiting time, how many features get done? Few features or likely much fewer.
Single Tasking and Partner Pairing
In this Single Tasking approach, developer and tester becomes a small team, and work on a single task/story. Developer thinks about implementation and tester thinks about test cases. They should interact with each other. Tester can understand the implementation and developer can the understand about the advanced test cases. E.g. what happens if we enter internationalization characters. Tester can also prepare the automation test. If we follow this approach both will benefit and they can deliver the next story with more quality as they know how developer and tester thinks. We need not follow this approach if our current approach Touch time is ok. Need to consider other tasks like planning and deployment while calculating touch time.
single tasking is not realistic as we need to catch up on email, meetings, support calls ... etc. We should calculate Touch time frequently and we need to work on changes to reach reasonable Touch time.
 |
| Ref: https://hakanforss.files.wordpress.com/2014/08/flowefficiencyformula.png |
In any ideal case if your doing the agile right way ,once a story is dev done, it should be immediately on QA plate. Lets consider you are in a two weeks agile model ,the decided code freeze is two days before the sprintend ,it is date just to stop the developer to check in any code changes and get testers time to check the product with a confidence that no more code will be checked in,which allows to test a stable code.
ReplyDeleteBurndown chart are another statistic ,in a scrum framework ,where burning of hours is important ,let it burn on day one or two it should not matter as of touch time. If this doesnt fit your requirement changes or working on different stories are more frequently changing you should shift to either kan-ban or lean rather than doing the scrum wrong way.