Scrum and TargetProcess

TargetProcess TargetProcess is a visual management tool used to manage and monitor processes Allows for easy visualization of work by all team members Allows management a tool for watching progress and measuring success

Scrum A way for teams to work together to develop a product Occurs in small pieces with each piece building upon previously created pieces. Encourages creativity Team takes ownership of the product Enables feedback and change Recommended video http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm Not enough time to give a full definition of scrum – took two days to get it in a course; Recommended video (will email the link)

Scrum Roles Product Owners Scrum Team Scrum Master Determines what needs to be built in the next 30 days or less Serves as the liaison with the stakeholders to report progress Scrum Team Delivers a release every 30 days that works Consists of developers and quality assurance Responsible for demonstrating what they built Scrum Master Facilitates the process

Creating the Project Step one Create your project We will use a basic version of the File Manager Rewrite project as our example 1 – Simple editor tool allows for full description of the project to be entered. 2 – Can also allow for file uploading for project documentation.

Adding Users Add users to project Simple to add both existing targetprocess uses and new users Show how easy to add a new user from this interface

Creating Backlog Different approaches Larger project with multiple teams Epics/Features followed by User Stories Smaller project with single team User Stories We will start with User Stories for this sample Very often in scrum, the Project Owner will hold a meeting with stakeholders and scrum team to help build the user stories before they are entered into this system. This helps to form a clear understanding of the project. User stories should also define when the user story is considered done with a consensus from everyone.

User Stories What is a user story? File manager project has one basic set of users so it will be simple (in scrum, simple is better) View Course Section Common and Content directories and their contents Create lessons, subtopics and pages Move lessons, subtopics and pages Delete lessons, subtopics and pages Each user story needs to define “done”

Create the Backlog The Backlog Board Usually set up by the Project Owner Simple to create a new Switch View structure eases the entry process Using shift click, user can drag drop priorities Set the business value – default Nice to Have Also demo the ability to change the board to separate into the business value

Map the Stories When Story Mapping is useful When you discover that many of the users stories should be grouped into one feature or release Possible Example Basic File Manager needs to be built before the rest of the project can be delivered. That may be the first release feature. Easy to create a feature from the Story Board; easy to create new user stories

Release Planning LET’S DO IT! Easy to create a release plan Let’s do it together but normally this would be done by the Project Owner and then reviewed by the Scrum Team in the Release Planning Meeting

Release Planning Meeting Estimation Game Different ways of estimating TargetProcess uses Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) http://en.wikipedia.org/wiki/Fibonacci_number Based on effort and is relative Only for current release Recommended Video http://scrumtrainingseries.com/BacklogRefinementMeeting/BacklogRefinementMeeting.htm recommend keeping things to a limit of 34 on our project sizes for scalability of the process Show them the poker cards; can also just use blank paper

Estimation Game Estimation based on Effort + Complexity + Doubts & Risks Each Scrum Team member displays a number that reflects how they view the effort of the user story. Some may think that the user story may be more complex than others. High number and low number hold a discussion and revote happens until a consensus is determined by the group. Remember to keep things “relative”

Iteration or Sprint PO builds the Iteration or Sprints Usually 30 days in length User stories are moved in during a Sprint Planning meeting with the Scrum Team This helps the team to understand the business value and take ownership of the process Let’s build an iteration so we can have our own Sprint Planning meeting – Use the iteration plan board First add a few iterations to use. Then have a sprint planning meeting

Sprint Planning Meeting Calculate Velocity for each iteration Total story points/number of iterations helps set the goal Considerations of team availability Move user stories into the iteration keeping an eye on the story points and velocity Building tasks

Building Tasks As a team, tasks are built for each story in the current sprint User Story = View directories/files, etc Design interface Program backend Program interface Testing – yes a separate task for each story! Team members work together to decide who will work with what task and adds the estimated time Testing can consist of two types – User Testing and Unit Testing. Building the Unit Tests may be a separate task in itself.

Sprint in Progress Daily Scrum Meeting Rules are simple! 15 minutes in length Same time each day All scrum team members attend PO does not attend but should be available to answer questions Only Three Questions! What did you accomplish yesterday? What do you plan to accomplish today? Any impediments? Scrum Master will ask the questions to each one at a time. Impediments are only mentioned and then will be discussed with the scrum master and anyone that needs to be part of the discussion after.

Daily Reporting At the end of the day, all scrum team members should report to the scrum master the task(s) that worked on with the time spent that day. Can be emailed to the Scrum Master or entered into the TargetProcess directly Very valuable to the scrum process!

Measuring Progress Burn Down Chart

What we don’t want!

Scrum Meetings Overview Sprint Review meeting happens after the Sprint is finished. PO, Stakeholders, Scrum Master and team area all present. Scrum team presents the sprint’s finish product demonstrating that the definition of Done has been met on any completed User Stories. Sprint Retrospective Meeting is just the Scrum Team and the PO to discuss the sprint overall. What did we do right, what can we do better? What issues have we faced?

Benefits to Scrum Happy Customers Reduced Product Costs See much faster results in increments Help define the process Reduced Product Costs Increased production speed Skipping work that is not essential to releasing a viable product Happy, Productive Team Building a product that gets released Takes ownership in the process

Benefits to TargetProcess Ease of usage to build and track Customization available based on roles APIs are available to help integrate other tools if desired