Necessity of high quality video training

Source: http://www.success.com/sites/default/files/styles/article_main/public/main/articles/Maybe%20Its%20Not%20ADHD_0.jpg?itok=Lfx-toWZ

Project Recap

Sprint Four of the MSCS Workflow Project was a struggle. At the end of Sprint Three, we anticipated the arrival of the OnBase sandbox. However, we have since lost communication with the SJSU IT Team. Therefore, we revisited OnBase training videos to educate ourselves further on the interface of the OnBase Unity and Web clients. Like the first time, we found the videos inadequate. The videos are long, wordy, and low quality. Furthermore, they were designed without target audiences in mind. Our objective is to create a user friendly implementation of OnBase. Without proper training, our intended audience would not use our product. For example, only the minority of SJSU staff and students use the Adobe Creative Cloud because they have not been properly trained to use the software.

What videos should be like...

I particularly like Jeremy Vest's description of "video" in his Six Steps to Creating High Quality Video Training:

Video is the fastest means currently available to create engaging online learning experiences, especially for the masses. Using video is an easy way to make a connection between the instructor and the learners.

Videos are meant to be quick learning tools, but I find the OnBase training videos difficult to concentrate on and distracting. The poor video quality and the unnecessary zooming in and out make it difficult to learn much about OnBase's interface. From the reviews, OnBase sounds like an excellent product; however, the development team really needs to up their game when it comes to producing quality training videos.

Tips

I find that we must create proper training videos before releasing the OnBase implementation to the SJSU MSCS Department. Therefore, I have found some guidelines for creating quality videos from Jeremy Vest's Six Steps to Creating High Quality Video Training and Mike Conaty's 5 Tips to Make Your Training Videos Less Mind-Numbing. 

1. Planning the video

I think it is very important to have a good story board and script before filming. We should set our learning goals and create a course outline. These are two important aspects of a real classroom.

2. Cut the lessons into smaller pieces

One thing I find most grueling about OnBase's videos is their length. These instruction videos should be quick and to the point.

Source: http://www.whiterosereader.org/wp-content/uploads/2015/03/video-editing-software-guide.jpg

3. Edit ruthlessly

The OnBase videos did not seem like they were edited at all. They were raw footage. The design was lacking. There was no coordination. The zooming in and out was disruptive.

Conslusion

These are only a few tips to proper training videos. However, I feel like this is an important topic for the scrum team and the project owner to study before attempting to make instructional videos or any kind of training modules.

References:
5 Tips to Make Your Training Videos Less Mind-Numbing. (n.d.). Retrieved November 24, 2015, from http://www.brunswickmedia.com/2011/04/5-tips-to-make-your-training-videos-less-mind-numbing/

Six Steps to Creating High Quality Video Training by Jeremy Vest : Learning Solutions Magazine. (n.d.). Retrieved November 24, 2015, from http://www.learningsolutionsmag.com/articles/185/six-steps-to-creating-high-quality-video-training

Team velocity versus team capacity

Team velocity and team capacity are significant concepts in agile development. They allow clients and management to understand the team's working ethic. My team was struggling with these concepts when completing our burn-up and burn-down charts; however, after some research and lecture, we have grasped these concepts. It is important for the client to understand team velocity and capacity because they summarize a team's work ethic--are they able to complete their tasks in a speedy and orderly manner?

What is team velocity?
Driving Velocity
As described by Catia Oliveira in Velocity on Scrum Alliance, "velocity is velocity. And velocity is measured . . . as velocity is." I particularly like the way Oliveira explains velocity because it is simple and relatable. She relates a project's velocity to driving.

How do you measure your velocity while driving? (Imagine the speedometer is broken.) You've been driving for the last two hours, you've gone 160 kilometers, so you know your average velocity is 80 km per hour.  

http://www.physicsclassroom.com/mmedia/kinema/fs.gif

Team Velocity

A project's velocity is measured in a similar way. "Velocity is the number of story points completed by a team in an iteration." To obtain an average velocity, simply add velocity from every iteration (distance) and divide by the number of iterations (time). 

https://www.scrumalliance.org/scrum/files/e3/e3a2ff2a-27a2-444c-81af-c2e8dbfb3128.jpg

Importance of Team Velocity

Team velocity is important because it allows the team to predict how much scope can be deliver by a specified due date. It allows the team to understand its limits while defining an amount of scope that can be committed within a sprint.

Can we compare velocity of different teams?
Product owners may want to compare the velocity of different teams to see which teams are more effective. However, comparing velocity will not help in comparing teams because they are using different units for their story points. Story points are relative to the team. One team can assign 20 points as an hour of work while another team can assign 60 points to the same amount of work.

One effective way to compare work ethic of two different teams is to compare their velocities to their team capacities.

What is team capacity?
According to Avienaash Shiralige, "team capacity is calculated as per people availability in that sprint." It must be determined before planning the sprint, so scope of deliveries can be estimated.

Let’s take an example.

Say team is of 5 people, then total capacity assuming 8 hour day, 2 weeks sprint(10 days) is = 5*8*10 = 400 hours. Planning for this total capacity will be disaster. It will lead to team working over time, rushing towards the end, quality cuts and low team morale.

In reality, management never plans for 100% capacity. They use a focus factor to determine real capacity. The factor usually lies in the range of 0.6 to 0.8. Therefore, a five person team working full-time would really only have a capacity ranging from 240 (400 * 0.6) to 320 (400 * 0.8) hours.

Why isn't capacity at 100 percent?
There are many factors in agile development that affect team capacity.

1. Team vacation
2. Scrum meetings
3. Defects
4. Training/Education
5. Administrative duties
6. Less mature team
7. New to agile
8. Complex product or new technology

Conclusion: Team velocity versus team capacity

To truly understand a team's work ethic we must compare its velocity to its capacity. Management must understand the time estimations behind story points and compare the time spent on tasks with team capacity to see if the team is utilizing its resources effectively.

https://i-msdn.sec.s-msft.com/dynimg/IC372417.png

References:

Oliveira, C. (2014, February 6). Velocity. Retrieved November 3, 2015, from https://www.scrumalliance.org/community/articles/2014/february/velocity

Shiralige, A. (n.d.). How To Do Effective Capacity Planning on The Scrum Team. Retrieved November 3, 2015, from http://www.agilebuddha.com/agile/how-to-do-effective-capacity-planning-on-the-scrum-team/