Practical Project Collaboration for Product Owners and Scrum Teams
•Als PPTX, PDF herunterladen•
1 gefällt mir•585 views
View the On-Demand Webcast! Planview.info/ScrumTeams Learn the definitions of Sprint, Epic, User Story, and Task in scrum project management and about roles like Product Owner, Scrum Master, and Scrum Team. Find out about the perfect beginner's tool for implementing agile scrum into your organization and how it can be used outside of software development in marketing, sales, event planning, and more! View the On-Demand Webcast! Planview.info/ScrumTeams
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (10)
Ähnlich wie Practical Project Collaboration for Product Owners and Scrum Teams
Ähnlich wie Practical Project Collaboration for Product Owners and Scrum Teams (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Practical Project Collaboration for Product Owners and Scrum Teams
- 1. © 2016 Planview, Inc. | 1© 2014 Planview, Inc. | 1 | Confidential© 2016 Planview, Inc. | 1 Scrum with Projectplace Zach McDowell
- 2. © 2016 Planview, Inc. | 2 • Welcome and housekeeping • The History of Agile Scrum • Vocabulary Lesson • Scrum Roles & Overview • Herding Cats: Agile Planning & Execution Agenda
- 3. © 2016 Planview, Inc. | 3 • Origins • Back to Basics Scrum & Projectplace
- 4. © 2016 Planview, Inc. | 4 Lean Software Development Written by Mary & Tom Peppendiek Kanban for Software Development Written by David Anderson Agile Manifesto Written by 17 authors at a ski resort in Sandy, Utah over a 3 day period Scrum Founded by Ron Jeffries, Ward Cunningham & Kent Beck Kanban Created by Taiichi Ohno @ Toyota The History of Agile Scrum 1940s 1995 2003 2001 2007 View the On-Demand Webcast!
- 5. © 2016 Planview, Inc. | 5 Scrum Vocabulary View the On-Demand Webcast!
- 6. © 2016 Planview, Inc. | 6 Sprint • A fixed-length iteration of work Epic • A very high-level description of an expected outcome. User Story • A concrete description of a piece of the epic’s expected outcome. Task • The individual work items required to finish a user story. Vocabulary Lesson View the On-Demand Webcast!
- 7. © 2016 Planview, Inc. | 7 • Projectplace employs 6 cross-functional development teams • Roughly 5-7 people per team • Migrated from JIRA to Projectplace 3 years ago • Projectplace runs 1 central workspace where planning & execution take place. Some Background View the On-Demand Webcast!
- 8. © 2016 Planview, Inc. | 8 Scrum Roles Designed by Freepik Product Owner • Ultimately representing the customer or end user, the product owner’s main responsibility is to define and prioritize epics and user stories Scrum Master • A facilitating role that will coach the team and the product owner in successfully following agreed-upon practices. Scrum Team • 5–7 people that represent the skills required to complete all work assigned to them. • A cross-functional team may also contain a technical lead as a point of reference for the Scrum Master and Product Owner. View the On-Demand Webcast!
- 9. © 2016 Planview, Inc. | 9 SquadDesigned by Freepik View the On-Demand Webcast!
- 10. © 2016 Planview, Inc. | 10 Daily Team Standup View the On-Demand Webcast!
- 11. © 2016 Planview, Inc. | 11 Feel like you’re herding cats? View the On-Demand Webcast!
- 12. © 2016 Planview, Inc. | 12 View the On-Demand Webcast!
- 13. © 2016 Planview, Inc. | 13 Setting up the Project Single Initiative Perpetual Project View the On-Demand Webcast!
- 14. © 2016 Planview, Inc. | 14 Sprint Planning - Waterfall Style Step #1 Step #2 Step #3 View the On-Demand Webcast!
- 15. © 2016 Planview, Inc. | 15 User Story Management View the On-Demand Webcast!
- 16. © 2016 Planview, Inc. | 16 Sprint Planning View the On-Demand Webcast!
- 17. © 2016 Planview, Inc. | 17 Sprint Planning Vol. I User Story Story Breakdown – Task Planning View the On-Demand Webcast!
- 18. © 2016 Planview, Inc. | 18 Sprint Planning Vol. II Story Breakdown – Task Planning View the On-Demand Webcast!
- 19. © 2016 Planview, Inc. | 19 Sprint Planning Vol. III Update all relevant metadata around a task Create D.O.D. checklist & attach files Time estimation & reporting Conversation & collaboration View the On-Demand Webcast!
- 20. © 2016 Planview, Inc. | 20 The Guillotine: Agile Execution View the On-Demand Webcast!
- 21. © 2016 Planview, Inc. | 21 Gantt Reinvented • Cards are associated directly to Activities on the project plan • Status of connected cards automatically reflected in associated Activities on the plan • Product Owner/Product Manager creates basic project plan/outline (classic WBS) • PO/PM to assist team with breaking down stories into executable tasks as cards • As cards are completed, inline progress bar shows real-time status of each Activity Classic Waterfall Plan Realistic Team Execution View the On-Demand Webcast!
- 22. © 2016 Planview, Inc. | 22 Task Burndown What is our current efficiency? Given our current efficiency, will we meet the target date? If not, what can we do to get there? Completion date if we continue at 2.9 cards per day Original target completion date, but requires almost 4x increase in efficiency View the On-Demand Webcast!
- 23. © 2016 Planview, Inc. | 23 Bringing it all together Grooming and Sprint planning sessions made easy Never miscommunicate priorities again Get right to the good stuff during daily scrum View the On-Demand Webcast!
- 24. © 2016 Planview, Inc. | 24 Projectplace is the perfect beginner’s tool for implementing Agile Scrum into your organization. Agile scrum is starting to bleed into other organizations outside of software development – Marketing, Sales, Event Planning, etc. Projectplace: One more thing View the On-Demand Webcast!
- 25. © 2016 Planview, Inc. | 25 Additional Information Thank you Questions? Free Trial Download Resources Request a Demo Contact Sales projectplace.com/pricing/enterprise-trial projectplace.com/resources projectplace.com/pricing/personal-online-demo salesna@projectplace.com “Projectplace is Synergy. The more we used the various capabilities of the [Projectplace] tool, the more synergy we had as a team.” “Expect rapid adoption. Projectplace is now universally adopted across IT for all projects larger than 100 hours and now other business stakeholders want to use it for their departments.” View the On-Demand Webcast!
Hinweis der Redaktion
- My name is Jason Morio and I will be moderating today’s webcast. Here’s what we have planned for today’s session: First, I will go over a bit of housekeeping Then we will move right into our Webinar on Scrum with Projectplace At the end of today’s webcast we will host a brief question and answer session
- Thanks for the intro, Jason! As Jason said, welcome to our webinar on Scrum and Projectplace – for our organization it has really been a match made in heaven... Hopefully we have people from all walks of life in the scrum/agile world joining us today...so, to start with, I’ll give a brief explanation of the origins of scrum and the vocabulary most closely related to the practice.
- So, before we begin, I thought that it’d be valuable to give some background on the history of agile scrum. It’s origins date back to the 1940’s within the Toyota Production System Toyota introduced and refined the use of kanban to standardize the flow of parts on their line They used kanban to signal stages in their manufacturing process and this became the source of truth for progress and status reporting. Of course, this enabled teams to be more collaborative and transparent during the production process. Hop in the time machine and join me in 1995, the middle of the .com boom, to Ron Jeffries, Ward Cunningham and Kent Beck inventing the concept of scrum. Defined as a flexible, holistic product development strategy where a development team works as a unit to reach a common goal Then all the way through today, innovators have been iterating, combining and improving processes around software development. This includes the publication of the Agile Manifesto and the realization that Kan ban works nicely with scrum/agile principles. Almost 80 years later, here we are. The problem is, though, how well are we following these principles in our day to day actions? How is stakeholder impact effecting the way we execute and communicate with our development teams? And most importantly, are we working as efficiently way we can as Project/Product managers, product owners, and scrummasters? For those beginners, we should define what these “scrum principles” I am referring to actually are.
- I’ll hop through this rather quickly, but this is an overview of some scrum terminology – again, this is vocabulary that will directly relate back to the
- A sprint is a time box for your team, whether it’s 1 week long or 4, this period of time will help your team make meaningful commitments, understand their capacity, and execute on releasable goals. The work included in a sprint is usually defined as the following two words, epics and user stories. An epic is a very high-level description of an expected outcome. For example: As a user I want to navigate across different tools at any given time, so that it is easy for me to navigate in and out of tools. As you can tell….this is pretty high level. What tools are we talking about? Where will they be?These epics, once written, are typically broken down into a more specific set of user stories. Normally this epic description also includes the value it provides to the target audience. A user story is a concrete description of a piece of the epic’s expected outcome. For example, using the epic we just talked about: As a user ( app. persona) I want to be able to navigate to the my overview screen from anywhere in the tools so that I can find all my work at one place. As you can tell, this example was a bit more focused on a specific executable, the my overview screen. Like epics, user stories are often broken down as well. This time into very specific individual tasks, this break down normally happens with the help of your scrum team. Then a task, an individual work item required to finish a user story, these are the objects that your development team will execute on. They might be design tasks, or front end tasks, whatever ios needed to reach a definition of done for the user story. Now where do these tasks go? Who executes on the plan filled with epics and user stories?
- Just some quick background on my time with Projectplace and how we have operated as a development organization. We employ 6 cross-functional dev teams, all of these teams is fully capable and equipped to work in any part of the code base. There are normally 5-7 people per team We normally employ 2 Front end developers, 2 backenders, an interaction designer and a visual designer. Depending on the team and it’s function, these numbers can change As an organization, we decided to move on from JIRA 3 years ago, in favor of our own product. This was an easy decision for us. It gave us the ability to hang out in our product everyday, act as end users – going through the same pains and successes as everyone else using Projectplace. This move also gave us the unique functionality to tie our longterm roadmap (or plan) to tasks in our kanban boards, where our teams execute….but we will get to that a little later on. Then finally, at Projectplace, we manage ALL of our development and product management work in one workspace – roadmap planning, sprint planning, and agile execution all take place here in various tools.
- Everyone has a role to play on a scrum team, everyone just as important as the last – The first is the Product owner – they are the voice of all stakeholders, whether they internal or external, team memebers or executives, prospects or current customers - it’s a part of the product owner’s job to identify and prioritize stakeholder needs and coherently communicate them to the team by way of epics and user stories. Next, we have our scrum master – the SM is the voice of the team, helps to define the intake and execution processes that best fit the team’s needs, and acts as a coordinator for the priorities defined by the PO for the team. Now we have the scrum team – Normally representing developers thatr make up a full stack – front end guys, some back enders and then (depending on the organization) a designer or two. At PP my average scrum team is made up of 2 front end developers, 2 back end developers, an Interaction designer and a visual designer. So the count normally sits at around 6 people but can scale up and down.
- Scrum and Baseball, not quite as different as you might think! Since we are in the middle of baseball season, and nothing quite says summer like our national pastime, let’s compare some of our scrum roles with positions on a baseball field. First we have our Product Owner, representing the coaching staff (Manager, first base coach, third base coach, etc.). It is up to the PO/Manager to make sure that the team is doing everything it can to accomplish their goal collective goal. The Scrum master, I have plugged in the Catcher position. Mostly because they are the field general, they call the plays/pitches, constantly communicate with the manager on the game plan…etc. The Scrum team makes up the rest of the diamond, position players in a cross functional environment, everyone has a specific strength and brings value to the unit as a whole. Now, with all of these developers running around ion the field, we’ll probably want someone to take the lead. In this scenario, the role of the pitcher will be played by the team’s technical lead. This resource usually has a wealth of knowledge behind the complexity of the presented problems as well as knowledge around how to go about this issue. Often times, the Tech lead and the scrum master will work together to create the best gameplan for attacking the sprint backlog. Just like a pitcher can shake off a sign from the catcher, a tech lead can let the scrum master know that their current plan could be made better or more efficient. Again, it is working as a team (manager, catcher, pitcher, outfield) that is the most important and required if you want to work/play efficiently. Now that the squad is set up, how can we best work together to stay transparent and collaborative? Having said that, I have one more piece of vocabulary to introduce….
- Finally, a daily standup with your cross-functional scrum team that should last no more than 15-30 minutes. You can go around the room and state (for each team member) 3 things: What have I done since the last meeting, what will I do before the next meeting, and is there anything preventing me from getting my sprint work done efficiently. This allows teams to stay in lock step throughout a sprint that may be filled with many different moving parts and requirements.
- For those of you that are already working with, in, or managing, scrum teams – sometimes, doesn’t it feel like your herding cats? With everything spread out, disorganized and just all together chaotic? With a myriad of stakeholders, requirements, deadlines, and execution styles, managing a scrum team can be overwhelming. You’re not alone…BUT…it doesn’t have to be that way. As a PM, PO, Scrummaster, Team lead, whatever you may be, Projectplace can help you tighten up, organize and start executing efficiently on your sprint and product goals. But how?
- I bet that many of you have this problem on a daily basis. Your stakeholders want a nice, tight, waterfall project view with start/end dates, a gantt chart, and a pretty work breakdown structure. However, we all know this IS NOT how team execution works in the day to day. If I were to show my team a WBS and Gantt chart, they’d say, “Great! But what are we supposed to do with this?” Teams will take more kindly to a well organized list of tasks, or at least, giving them the ability to create a comprehensive list of tasks needed in order to complete the various deliverables in the waterfall plan. The best part about Projectplace is that, as a PO, I can support both my stakeholders and teams with different features in the product!
- Depending on the scope and duration of your initiative, there are two suggested approaches to your project set up. The perpetual project is how we run our dev organization here at Planview and Projectplace. We like to keep a historical record of all the work we’ve done over time while also keeping an up to date plan for the coming 6 months of our roadmap.
- Now, most of you, I hope, have worked with a work breakdown structure….it is basically just an outline for work that needs to be accomplished in a specific time frame. Think of it like an outline you did for a college research paper or a hierarchical list…that’s all it is, not scary at all. (Click) Step One Create a level for your upcoming sprints. I like to organize my structure like this so I can easily navigate through it, when I know exactly what I am looking for. Within your upcoming sprints activity, give it some children, for the sprints coming up in the next few weeks/months/years – how far you go is your prerogative. As you can see, each sprint is in a time box – for example our June sprint starts on May 23 and ends on June 24. ….Now, within each sprint….. (Click) I like to break out each one by team – so you can see, in our March sprint, I have created two activities for Team alpha and team beta. Within those, (Click) In step 3…. I start to build out my high level epics and user stories. This is where I define the higher level priorities for my team for that particular sprint, based on roadmap and stakeholder requirements. You’re probably wondering where we put epic and story data, how do I know what a story requires just by a name? (click)
- Well, when we drill into one of our stories, you can see…… (Click) All the metadata necessary to understand the story and further break it down with your team. The story is clearly defined in the description (read it) and it has a time box for the sprint that it belongs to. You can also, add cards also known as tasks to the story for execution as well as documents – these might be a specs or designs needed to accomplish the final goal of your story. (Click)
- Which brings us to sprint planning! Hooray!, everyone’s favorite activity. Sprint planning is the time where you go over all of the defined stories with your team and break them down into executable tasks – Normally, teams will estimate each story based on points which is just an indicator of complexity – commonly teams will use the Fibonacci sequence to define the point total. The end goal of sprint planning is to get a firm commitment from your team as to how much they can accomplish during your defined sprint. Depending on your teams, this isn’t always the easiest feat. (Click)
- So during sprint planning, it’s best to go over each story, in depth with your team. The team will normally like to know the who, what, when, and why of the story – but it’s important to let the team define the how. (Click) (Click) In the details pane in the plan – you can easily break down the story with your team into tasks or cards – making sprint planning pretty seamless, in my experience. (Click)
- Once you’ve broken everything down into cards – we break them out onto a kan ban board. (Click)
- Once we dig into a card, much like the details pane for the story/activity – we have a bunch of collaboration tools and metadata available to be as specific and squared up as possible. (Click)
- As work gets done, this is what the progress activity will look like on your board – but how does this picture of progress tie back to the plan? The plan and gantt chart are what my executive stakeholders want to see, something that will give them a solid idea of progress without having to translate a kan ban board…let me explain -> (Click)
- This is the concept of Gantt Reinvented… and it’s something unique to Projectplace Gantt Reinvented is our unique combination of your classic Gantt chart in concert with kanban boards that lets you plan, track, manage and communicate the status of work in whichever way suits your purpose. As a product owner, product manager, however you identify, you can craft the high level project plan with epics, user stories, milestones, dates, durations and dependencies as a Gantt chart When it comes time to break down those activities to the actual “executable level”, you and your teams flip over to kanban and build out the boards and cards to track and manage the execution of those activities Then, individual cards can be connected or associated back to the relevant activities on the Gantt chart, which creates an inline progress meter on that activity And as connected cards are moved to the Done column, the inline progress meter on that activity automatically reflects this update, on and on until all cards are completed and the meter is full This simple but elegant concept enables you to get the best of both worlds and creates that bridge that will keep both your teams and your management happy
- It has been working for us, internally. I’m sure some of you have more advanced needs in your scrum processes, like release planning and code check ins Agile scrum is starting to bleed into other organizations outside of software development – our Marketing team here at Planview had tried Trello, Asana, and JIRA before finding the light and coming over to the Projectplace side…if you want to hear more about this, look out for our Director of Interactive Marketing’s webinar that’s coming in a couple of weeks! And…with that, I’d like to thank everyone for their time and attention for the last half hour or so – I hope there was something in here for everyone to take home with them.
- For more information, visit us at projectplace.com Don’t forget to download your handouts from the Handouts section in the GoToWebinar panel And stay connected by following us on social media