Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

How to use Agile with Scrum Project Management on any type of project

A brief introduction and beginning stage of Agile with Scrum conversion to any type of project. First know the basic terms, how the methodology works, how it can be applied and what would change when converting.

Quaisha Thornton, Blogger

December 9, 2011

11 Min Read

How to use Agile with Scrum Project Management on any type of project

 

Agile with Scrum is popularly used with software projects, however, it can be adjusted to any type of project that requires a continuous cycle of requirements, planning, executing, controlling and monitoring.

 

My Qualifications of Using Scrum

  • I do not have or plan to start a software project.

  • I am a freelance writer and plan to start an online-based business.

  • I am a beginner in Scrum and in project management with no experience aside from research and using techniques in my own projects.

  • I also do not have practical business knowledge as I am just a marketing coordinator and founder of a gaming website and a few blogs.

  • The following written process is how I will use Agile with Scrum on my own non-software projects.

 

Before using Scrum with any type of project, it's important to know what Scrum is and how it works. I will go over some basic Scrum terms and how it generally works. For more detailed information I have listed some e-books that I personally used to help me understand Scrum.

 

Definitions of Terms

 

  1. Scrum: A framework used to address complex adaptive problems or simplify processes in project or program management.

  2. Agile Project Management: an approach to project management based on the principles of human interaction management. The project is in a flexible state with a series of relatively small tasks conceived and executed as the situation demands always adaptive to the environment.

  3. Product Owner: One person responsible for maximizing the value of the product and the work of the Development Team; managing the Product Backlog.

  4. ScrumMaster: One person responsible for ensuring Scrum practices, rules and theories are understood and enacted; governs those outside the Scrum Team limiting helpful or non-helpful interactions with the Scrum Team.

  5. Development Team: Professionals that are self-organizing and cross-functional who do the work of delivering a potentially releasable increment of“DONE” product at the end of each sprint.

  6. Shareholders: They represent the owners, investors and top management of the company that produces the service, product or program.

  7. Sprint: a time-boxed action item(s) of one month or less during which a “done”, useable, and potentially releasable product Increment is created.

  8. Release: a time-boxed group of sprints to be worked on incrementally.

  9. Requirements: what the product needs to be appropriate, competitive, and useful. It's always evolving.

  10. Increment: sum of all the Product Backlog items completed during a Sprint and all previous Sprints.

 

 

How Scrum Works

 

In Scrum, there is a Scrum Project Team that includes the Product Owner, The ScrumMaster, and the Development team. The Product Owner is responsible for taking input from shareholders, users who represent them and customers and using it to create an extensive list of requirements called a Product Backlog. In the Product Backlog are short User Stories gathered prior to the Release and Sprint planning meeting. User stories are goals that need to be completed in the Sprints.

 

 

The Scrum Cycle

 

Gather requirements to work with (initiating) => Turn requirements into user stories => have release and sprint meeting to assign sprints to team => Do sprints (sprinting or executing) => Have daily scrum meetings to inspect and adapt or control and monitor progress of the team => Testing => Sprint review meeting => Gather feedback and input, add to backlog (also include items that didn't make sprints or additional requirements) to plan the next set of sprints => Release and Sprint meeting => End (when project is no longer funded or being updated)

 

 

 

Image from Scrum in action Agile Software Project Management and Development 2011 e-book.

What will change when using Scrum for a non-software project?

 

The elements that will be affected when adapting Scrum for my project:

 

  • Shareholders – Shareholders will involve investors, affiliates and/or sponsors and their input is limited since I am the founder/creator of my own project.

 

  • Product Owner and ScrumMaster – I will be the product owner, could split up the ScrumMaster roles amongst my team or combine the duties of product owner and ScrumMaster.

 

  • Development team – Instead, of a software development team or software-related members, I will have a team of writers, a graphic designer, a web or creative designer, a community manager. The obvious roles such as content management, marketing, PR and business manager will be handled by the creator of the project/Founder/CEO.

 

Modifying these elements results in a slight change of the overall Scrum process – a faster collaboration amongst the Scrum team. Since most requirements gathering rely with the new type of Product Owner's own goals for the project, the Product Backlog might not be shorter, but the time it takes to make them into comparable User Stories is shorter. Some duties of ScrumMaster and Product Owner are shorter also as a result. Meetings are not affected by the modified elements.

 

Details of Scrum Meetings

 

Release planning – the scrum team identifies all the product releases that should have completed or should be updated along with a probable delivery schedule. (meeting lasts 1 hr for each week of a sprint release: for example, it lasts 4 hours with a four-week sprint)

 

Sprint Planning- To discuss what each sprint is, to assign what each sprint and to allocate time to the sprints for a balanced effort.

 

Pre-Release and Sprint Planning meeting (lasts 1-2 days; 8 hours for sprints of 4-week divided into two phases)



  1. 1st phase of meeting - to discuss the "what" question. The team goes through user stories to decide which ones will be part of which sprint and what their goals are.

  2. 2nd phase - to discuss the "how" question. The team identifies tasks from previously chosen user stories, assign time in hours how long it will take the team to produce a working product or project for consumer use. Then these tasks are assigned to a task board for easy team allocation and time management.

 

Post-meetings into the actual sprint work

  • 15-min daily Scrum or Daily Standup - to discuss the team's progress towards the Sprint goal of the current sprint release.

  • Create a chart to show how much remaining work until the team is done with the sprint. Should be updated by the ScrumMaster or Product Owner when team doesn't have time.

Sprint Review meeting (lasts up to 4 hr if sprint release is up to 4 weeks)

  • the team meets with the product owner to go through a sprint review organized by the scrum master.

  • Three objectives are discussed: discuss what was done and what was not done; demonstrate what was built and get feedback; get updates from product owner regarding any new changes to project or market direction.

 

Post-sprint review meeting, pre-sprint meeting (same time length of release planning meetings)

  • Discuss what worked and didn't work in prior sprint and how to change for a more effective collaboration going into next sprint. It's a sprint retrospective meeting.



Here are some tips:

  • If a project doesn't have a ScrumMaster role, disburse duties amongst the team. If wanting to combine product owner and ScrumMaster, make sure to let team know when acting in either role for certain tasks.

  • If you can't meet in person for meetings, use Skype and an electronic task board.

  • For testing purposes, depending on your project, release a beta to get feedback from users and then put the project in maintenance for 24 hours to fix issues.

 

  • What would be continuous integration tools? Whatever tools is used to manage information from the business objectives to the team. In other words, supporting tech and infrastructure tools. Need to be trained in these techs. Since Scrum is a project management system, any sufficient project management application preferably web-based that can easily collaborate with the team. I'm currently trying Trello, a web-based task board management system. This website provides a list of some Agile tools.

 

  • A product owner could be a business manager or analyst.



Conclusion

Scrum is my ideal Agile project management methodology for small to medium projects of continuous integration and adaption. It's rather easy to learn the fundamentals starting with remembering the Agile Manifesto and PM Declaration of Interpendence. It's not so easy implementing the framework within an organization that has a waterfall project management already in place. Scrum is not for everyone but can be very successful if you have a good team and a management system.

Before trying Scrum for your project, take an assessment test that is located in this ebook: Scrum in action Agile Software Project Management and Development 2011

This guide simplified some theories and process and is easy to understand:

The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game

 

 

Certifications in Scrum:

 

  1. Certified ScrumMaster (CSM)

  2. Certified Scrum Product Owner (CSPO)

  3. Certified Scrum Professional (CSP)



Project Management Certifications



  1. Project Management Professional (PMP)

  2. Project Manager for Technology or Project+ (PMT or PMP+)





Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like