Download as PDF, PPTX
![WriJng
Useful
Stories
• Think
about
the
end
result
you’re
trying
to
achieve,
and
try
to
aFack
it
in
ways
that
will
ensure
you’re
delivering
some
value
to
some
user
at
least
every
sprint,
even
if
that
user
is
yourself
as
a
developer.
• Follow
the
template:
– As
a
[user
role],
I
want
some
[goal]
so
that
[reason].](https://image.slidesharecdn.com/product-management-tools-121017162518-phpapp01/75/How-to-Create-a-Product-Management-Process-That-Doesn-t-Suck-43-2048.jpg)
Uploaded byIntelligent_ly
How to Create a Product Management Process That Doesn't Suck
Cory von Wallenstein's presentation at Dyn Inc. outlines a product management strategy that emphasizes the importance of creating differentiated products for market success, contrasting them with 'me-too' products. It details the roles and collaborative processes of product and project management, including feature requests from various stakeholders, backlog prioritization, and the execution of sprints to deliver value. The document further explains the development workflow using Agile principles, focusing on defining tasks, assigning them, and managing releases effectively.
More Related Content
Similar to How to Create a Product Management Process That Doesn't Suck
How to Create a Product Management Process That Doesn't Suck
- 1. presents CORY VON WALLENSTEIN ChiefTechnology Officer, Dyn Inc. @cvonwallenstein Tools of the Trade: Creating a Product Process that Doesn’t Suck
- 2. “Truly Superior, Differen1ated” Products had an average 98% success rate and 53.5% market share. “Me-‐Too” Products averaged an 18.4% success rate and 11.6% market share. Product Leadership: Crea2ng and Launching Superior New Products – Robert G. Cooper Photo Credit: h2p://www.flickr.com/photos/idletype/526824467/
- 3. Agenda 1. Product Litmus Test – Is this working? 2. Product vs Project Management – Role in org 3. Deep dive! 1. Product management top to boFom 2. Teams driving toward success 3. Keeping the company in the loop
- 4. But First, Who Is Dyn? • 170 Global Employees • Headquarters in Manchester, NH • Offices in San Francisco and Brighton, UK • Raised first financing in Oct 2012: $38MM from NorthBridge
- 5. Product Litmus Test Is this working?
- 6.
- 7. Is what we’re doing now working? • Is there a palpable divide? – When will X be done? – What’s blocking X? • Is it a bug or a firewall config or logo or contract? – When can we start Y? – What’s the priority in the grand scheme of things? – Is Kari available to help with something next week? – When can we safely switch gears? – What defines 80% complete?
- 8. Manifesto for Agile So<ware Individuals and interac1ons over processes and tools Working so<ware over comprehensive documentaJon Customer collabora1on over contract negoJaJon Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the le< more. hZp://agilemanifesto.org
- 9. Product vs Project Management What is the role of Product Management in the org?
- 10. What is Product Management? • Read a great overview presentaJon
- 11. What is Product Management? • At Dyn Inc., largely concerned with what features and improvements go into the products in what order. • Ideas for features and improvements come from everywhere – Prospects, customers, internal teams, etc. • Collaboradve process with execs and directors to set priorides for what to take on, and when • Funcdonal specificadons for what is to be built
- 12. What is Project Management? • At Dyn Inc., largely concerned with coordinaJon of resources to efficiently execute on the plans set forth by product management. • CollaboraJve process between directors and managers to set schedules, remove roadblocks and communicate progress. • Most important: Deliver value constantly.
- 13. Few Quick DefiniJons •Sprint – Easy definiJon: Up to two weeks of work. You’ll hear it used as “current sprint” and “next sprint”. – Complete definiJon: One or two weeks on the calendar (defined by directors/managers), such that all work assigned to the sprint will be complete by the end of the sprint. Well defined points to flexibly change focus before or a`er a sprint.
- 14. Few Quick DefiniJons •Story: A business focused descripJon of new or changed funcJonality that can be done in one sprint. To be divided into technical and business tasks. hZp://www.slideshare.net/rwirdemann/user-‐stories-‐for-‐your-‐product-‐backlog
- 15. Few Quick DefiniJons •Epic: A collecJon of stories that span sprints. • Technical task: Technical work required to bring a story to fruiJon. Design architecture, write code, create mockup, code review, etc. • Business task: Non-‐technical work required to bring a story to fruiJon. Define objecJves/ goals/measurables, write specificaJon, create graphics and content, blog entries, etc.
- 16. Few Quick DefiniJons •Bug: Broken funcJonality that needs to be corrected. Bugs do not describe new funcJonality, only exisJng funcJonality that no longer works. • Feature Request: New funcJonality. • Improvement Request: ExisJng funcJonality that works as designed, but could work beFer.
- 17. Deep Dive! Let’s see this process and tools in acJon!
- 18. How does it come together? Feature Requests • From prospects, customers, internal teams, etc., all the ideas we may do, sorted by priority • We track who asks for what, and how frequently • Execs, VPs & directors keep three sorted priority lists by category: DNS, Email & Internal • We conGnuously add new requests, and we review prioriGes minimum of 2x per week. Product Backlog • Feature requests are work we may do; the product backlog is work we will do, sorted by priority. • The top priority requests get evaluated in detail, with a target pace of 1-‐2 per week • VPs use a product lifecycle process to figure out what’s needed to implement the request, directors write specificaGons (e.g., epics and stories), and get ready for teams to execute. Sprints and Releases • Directors and managers define the work described by stories into actual tasks, and schedule efforts. • Managers work in two week sprints, each culminaGng in at least some value delivered to someone. • On release of large efforts (e.g., epics), VPs & directors coordinate the launch using a product lifecycle process again.
- 19. Feature Requests • From prospects, customers, internal teams, etc., all the ideas we may do, sorted by priority Product Backlog • Feature requests are work we may do; the product backlog is work we will do, sorted by priority. Sprints and Releases • Directors and managers define the work described by stories into actual tasks, and schedule efforts. • What Does Product Planning Mean? 1. Get the ideas
- 20. Feature Requests • From prospects, customers, internal teams, etc., all the ideas we may do, sorted by priority Product Backlog • Feature requests are work we may do; the product backlog is work we will do, sorted by priority. Sprints and Releases • Directors and managers define the work described by stories into actual tasks, and schedule efforts. • What Does Product Planning Mean? Kicka 1. Get the ideas 2. Priori0ze the ideas, driven by opportunity, pain, number of customers.
- 21. Feature Requests • From prospects, customers, internal teams, etc., all the ideas we may do, sorted by priority Product Backlog • Feature requests are work we may do; the product backlog is work we will do, sorted by priority. Sprints and Releases • Directors and managers define the work described by stories into actual tasks, and schedule efforts. • What Does Product Planning Mean? Kicka 1. Get the ideas 2. Priori0ze the ideas, driven by opportunity, pain, number of customers. 3. At a high level, what needs to be done? That’s the func0onal specifica0on.
- 22. Feature Requests • From prospects, customers, internal teams, etc., all the ideas we may do, sorted by priority Product Backlog • Feature requests are work we may do; the product backlog is work we will do, sorted by priority. Sprints and Releases • Directors and managers define the work described by stories into actual tasks, and schedule efforts. • What Does Product Planning Mean? Kicka 1. Get the ideas 2. Priori0ze the ideas, driven by opportunity, pain, number of customers. 3. At a high level, what needs to be done? That’s the func0onal specifica0on. 4. What are the tasks that bring this idea to life? Where do they fit in the schedule? What non-‐technical tasks are required to make it successful?
- 23. What Does Product Planning Mean? 1. Get the ideas 2. PrioriJze the ideas 3. Specify the funcJonality for the idea 4. IdenJfy the tasks required to bring the idea to life, and schedule the tasks for teams to work on.
- 24. 1. Get the Ideas • Primarily in the form of feature requests and improvement requests that come from the dashboard • Click “Feature Request” or “Improvement Request” for DNS, Email or Internal.
- 25. Examples of Feature Requests Customer Idea for New Funcdonality • Example request:
- 26. Examples of Feature Requests Customer Idea for Improvement • Example request:
- 27. Examples of Other Feature Requests • Could be an improvement to a UI or workflow – Include screenshots that show where the confusion or pain is, or under what circumstances the pain is introduced • Could be a change to how a service works – For example, on failover of a hostname, provide just the failover IP for the purpose of secondary DNS providers to consume. • Could be an internal improvement request – For example, connect our Salesforce.com account to other systems – Speed up a tool that is slow
- 28. 2. PrioriJze the Ideas • ConJnue to add addiJonal support for ideas as new customers request the same features or improvements • Comment on ideas to add support • Vote on ideas • Directors and execuJves: Adjust the prioriJes of the ideas
- 29. Add addiJonal support •Has another customer requested a feature that we’re already tracking? Add them! • Add another row to the table in the descripJon
- 30. Comment on ideas •Add your insights, addiJonal customers to look at, and other ideas that can help decide where this should sit in the priority stack.
- 31. Vote on ideas •VoJng is another way to register your support, parJcularly for internal feature and improvements that make our lives easier.
- 32. PrioriJzaJon in AcJon •VPs, execs & directors review and adjust prioriJes 3x per week. • Be sure to leave a comment as to WHY you changed the priority! • Priority adjustments appear in the history of the issue for who changed what and when, and will alert via an email noJficaJon to watchers.
- 33. PrioriJzaJon in AcJon Changing rank logs the change and sends a no0fica0on Be sure to comment WHY you made the change, especially if bumping to at or near the top.
- 34. Feature Requests • From prospects, customers, internal teams, etc., all the ideas we may do, sorted by priority Product Backlog • Feature requests are work we may do; the product backlog is work we will do, sorted by priority. Sprints and Releases • Directors and managers define the work described by stories into actual tasks, and schedule efforts. • Requests in a Queue vs Stories in a Backlog Kicka The JIRA issue types of “Feature Request” and “Improvement Request” represent the never ending “wishlist”. Ideally it’s a mess, because it’s everything, and we have yet to sort through which requests we’re taking on and which we are not. The JIRA issue types of “Story”, “Bug”, “Epic” and the sub-‐tasks represent work we have definitely agreed to take on, scope out, and deliver. It’s just a maer of scheduling. This is the backlog! It’s ideally clean, because it’s stuff we have agreed to take on. The “Request” issues link to the associated backlog issues in JIRA.
- 35. 3. FuncJonal specificaJons 4. IdenJfy tasks, assign & schedule • We’ll cover these in detail in the final secJon of the training on “Teams driving toward success” and day-‐to-‐day JIRA usage.
- 36. Teams Driving Toward Success • WriJng really useful: – Bug reports, stories and epics – Technical and business subtasks – FuncJonal and technical specificaJons • Workflows for issues and transiJons • Scheduling sprints, due dates and releases • Keeping your plans accurate to reality • CreaJng and using dashboards to stay in the loop
- 37. WriJng Useful Bug Reports • Bug: Broken funcJonality that needs to be corrected. Bugs do not describe new funcJonality, only exisJng funcJonality that no longer works.
- 38. WriJng Useful Bug Reports • Use the summary to describe what is broken and the impact in plain English. • Good examples: – Users from Canada cannot checkout their cart because they are marked as fraudulent purchases. – Zone changes larger than 50 resource records in size fail to publish. – Leaving TTL text field blank throws HTTP 500 to user.
- 39. WriJng Useful Bug Reports • Use the summary to describe what is broken and the impact in plain English. • Bad examples: – Checkout error – Line 50 of checkZone.pl is wrong – Internal Server Error 500
- 40. WriJng Useful Bug Reports • In the descripJon, include steps necessary to reproduce the bug. • AFach a screenshot or otherwise capture the “evidence” that the bug exists, and place in the descripJon.
- 41. Few Quick DefiniJons •Story: A business focused descripJon of new or changed funcJonality that can be done in one sprint. To be divided into technical and business tasks.
- 42. WriJng Useful Stories •Why bother with the whole story thing? – Convey what’s going on in terms anyone can understand. – Force us to think about taking on work in small chunks, so we can conJnuously deliver value and be nimble to changing course if necessary. Stories cannot span sprints. – Define what value is geong delivered for whom to set clear expectaJons on what “done” means.
- 43. WriJng Useful Stories •Think about the end result you’re trying to achieve, and try to aFack it in ways that will ensure you’re delivering some value to some user at least every sprint, even if that user is yourself as a developer. • Follow the template: – As a [user role], I want some [goal] so that [reason].
- 44. WriJng Useful Stories •As large efforts progress, you’ll start to see the value shi` from internal to external user roles. – First sprint: As a developer…; As a tester…; – Second sprint: As a system administrator…; – Third sprint: As an internal alpha user…; – Fourth sprint: As a closed beta user…; – Fi`h sprint: As a customer…; – Sixth sprint: As a customer…; – Seventh sprint: As a customer…;
- 45. WriJng Useful Stories •If the story implements a Feature Request or Improvement Request, link it! • More Acdons -‐> Link, then search for the issue • Use “implements” going from Story to Feature/Improvement request. Automadcally creates reverse link of “is implemented by”.
- 46. WriJng Useful Stories •The descripJon of the story contains any necessary implementaJon details and technical specificaJon, like mockups, architecture diagrams, state diagrams, etc. • Include pictures, create Gliffy diagrams, link to documents in Confluence. • We’ll explore breaking the story down into tasks a`er we look at epics real quick…
- 47. WriJng Useful Epics •Epic: A collecJon of stories that span sprints. • Only needed if it truly spans sprints.
- 48. WriJng Useful Epics • Summary describes the effort – High availability for portal and API – Geo Traffic Management • DescripJon contains the project-‐wide technical specificaJon – Remember, the funcJonal specificaJon is tracked on the Feature Request or Improvement Request. – Large efforts have tech specs on epics; small, less than two week efforts have tech specs on story
- 49. WriJng Useful Epics •On your stories, be sure to set the Epic. It has to be explicitly set on each Story. Can be bulk changed.
- 50. WriJng Useful Sub-‐tasks • Sub-‐tasks are where we define the actual work that needs to be done, by whom, and by when. • Free to use summary and descripJon as necessary to convey task requirements. • OK to group smaller tasks in the descripJon of a sub-‐ task as a bulleted or numeric list (e.g., ten things that each take 5 minutes…) • Technical (write code, install package) and business (create logo, sign contract) sub-‐task types.
- 51. WriJng Useful Sub-‐tasks •Most important: TIME ESTIMATES! • Used for the burndown charts, that convey to the rest of Dyn Inc. when an effort is expected to be completed.
- 52. WriJng Useful Technical Sub-‐tasks
- 53. WriJng Useful Business Sub-‐tasks • Logos, contracts, feedback, approvals, etc.
- 54. WriJng Useful FuncJonal Specs • What does the implemented idea look like? What are the requirements? How do you define it’s done and it’s successful? • Describe with user stories, workflow diagrams, and interface mockups • Leave no quesJon unanswerable.
- 55. WriJng Useful Technical Specs • How are we going to implement the funcJonal specificaJons? • System architecture, state diagrams, pseudo-‐ code as needed to convey how to implement. • If the funcJonal specificaJons live on (or are linked from) the Feature or Improvement request, the technical specificaJons live on (or are linked from) the highest level Epic or Story for the effort.
- 56. Workflows for Issues • Open or Re-‐opened -‐> In Progress -‐> In QA -‐> Closed • What does Open mean? – Queued up for an individual to work on according to priority stack. • What does Re-‐opened mean? – It previously went through at least up to In QA or Closed, and needs more aFenJon that’s not being given right this moment (otherwise, would have gone back to In Progress).
- 57. Workflows for Issues • Open or Re-‐opened -‐> In Progress -‐> In QA -‐> Closed • What does In Progress mean? – You’re working on it today. OK to have more than one In Progress if you’re working on more than one thing in a day. Not OK to leave it In Progress if you’re not working on it today. • What does In QA mean? – Ready for peer review. TransiJon to In QA and assign to a peer who will review the funcJonality. EVERY issue gets peer reviewed.
- 58. Workflows for Issues • Open or Re-‐opened -‐> In Progress -‐> In QA -‐> Closed • What does Closed mean? – If In QA failed (e.g., more work or changes required), goes back to original assignee and either Re-‐opened to work on later or In Progress if they’re going to jump on it now. – If it passes peer review, can be Closed, which signals that it’s ready for the next release.
- 59. Scheduling Sprints, Due Dates and Releases • Really only two contexts to use the term “sprint”: – The current sprint: Defined value that the teams are commiFed to delivering in two weeks or less on the calendar. Working on it now. – The next sprint: Defined value that the teams are commiFed to delivering in two weeks or less on the calendar… as soon as the current sprint is delivered. • Anything beyond “the next sprint” is prioriJzed in the backlog. That’s it.
- 60. Scheduling Sprints, Due Dates and Releases • OK, we have our sprint scheduled, what about release? – A version in JIRA is a release to producJon. When you know you’re going to take advantage of a code release day to release code, create the appropriate version in your project with the “release date” set to your release day. – Set the “fixversion” on your issues to indicate what will go live in the version. These will later become your release notes.
- 61. Scheduling Sprints, Due Dates and Releases • We missed the due date! We’re late! OH NOZ! – Not to worry, these things will happen. – What’s important is to communicate to the team: 1. That it happened. Don’t sweep it under the rug. 2. Why it happened, so you can think about what to keep in mind for next Jme. 3. What the new plan is… adjust your fix versions, due dates, and other planning as needed. Comment on the issues! • There are lots of perfectly valid reasons why plans may change, but there is no excuse for ignoring the change.
- 62. Keeping your plans accurate to reality • Here we’ll cover: – Due date maintenance, or “we’re clearly not going to get all of this done for release day” – Burndown charts, or “when is project X going to be done?” – Time tracking with SVN, or “keeping our burndown charts up to date with minimum effort”
- 63. Due Date Maintenance • When changing dates on a fixversion, all issues assigned to that fix version must be changed as well – Create issue filter with fixversion of ‘x.x.x’ – Apply bulk change to all issues matching filter – Leave comment as to why change was required
- 64. Due Date Maintenance • When changing dates on a fixversion, all issues assigned to that fix version must be changed as well – Create issue filter with fixversion of ‘x.x.x’ – Apply bulk change to all issues matching filter – Leave comment as to why change was required
- 65. Burndown Charts • Burndown charts require start and end date be set in Chart tool – Create a filter based on FixVersion – Add Burndown chart to dashboard – Set start and end date on info tab
- 66. Burndown Charts • Burndown charts require start and end date be set in Chart tool – Create a filter based on FixVersion – Add Burndown chart to dashboard – Set start and end date on info tab
- 67. Time Tracking with SVN • Use the # when checking in to record Jme and comments svn commit -‐m "ECTE-‐862 Created basic interac0on #0me 2h”8asic in #resolve and #close work too
- 68. Puong It All Together A Dashboard in Confluence that the whole company can read.
- 69. Kickass Products at Dyn Inc! Feature Requests Product Backlog 3-‐5 High Profile Projects at Dyn Sprints and Releases Each pordon of the process has a corresponding pordon of the dashboard: 1. The high profile projects are at top for easy reference • This is what most folks will be interested in… when is X going to be done? • Not part of the “flow”, just a handy reference secdon. 2. Feature requests for DNS, Email and Internal in sorted priority. 3. Next is the product backlog in sorted priority by team. 4. Followed by the current sprint, with work grouped by team.
- 70. High Profile Projects Let’s look at the first secJon in detail: the High Profile Projects. The goal of this secdon is give you a quick pulse on the top 3-‐5 efforts at Dyn that everyone cares about. You’ll see whether or not the effort is acdvely being worked on, and when it’s expected to be complete. Have it open? Good!
- 71. High Profile Projects •Three porJons to pay aFenJon to: – Switching between the 3-‐5 high profile projects – The project card, which gives an overview of the effort, and links to the associated informaJon in JIRA if you’d like to dive into the details. – The burndown chart, which plots calendar days on the X-‐axis and hours remaining on the Y-‐axis. When hours remaining reaches zero, the project is complete!
- 72. High Profile Projects Switch between projects by clicking the tabs. What projects are shown are determined by CvW, so send a request if what you seek isn’t shown.
- 73. High Profile Projects The card view shows the parent issue in JIRA (likely a Story or Epic, here it’s a Story), with a summary of the effort, what version it will release in, and the assignee who is the person that is most familiar with the effort.
- 74. High Profile Projects The burndown chart shows you in real-‐0me when this project is likely to complete. The red line is a guideline predic0ng comple0on, and the green line is work remaining. When work remaining reaches 0, the project is done. Read more about burndown charts.
- 75. Feature Requests Let’s look at the second secJon in detail: Feature Requests. The goal of this secdon is show the ideas we may want to work on, in sorted priority. Each week, teams take the top 1-‐2 feature requests and spend dme figuring out what it would take to implement them in the form of a funcdonal specificadon. This specificadon gets translated into stories, which will appear in the backlog. Have it open? Good!
- 76. Feature Requests • Few porJons to pay aFenJon to: – Categories of requests: DNS, Email and Internal – InterpreJng the status of a request – Sorted prioriJes, and how to change them – Going beyond the top 10 prioriJes – Diving in to a feature requests – CreaJng new feature requests vs improvement requests
- 77. Feature Requests Three sec0ons, lea to right: DNS, Email and Internal. DNS includes all DNS products and services, Email includes all Email products and services, Internal includes everything we rely on internally (Salesforce, Phones, Zimbra, RT, Billing Portals, etc.).
- 78. Feature Requests Let’s zoom in on DNS. Everything we look at from here on is equally applicable to DNS, Email and Internal, we’re just using DNS as an example.
- 79. Feature Requests Four pieces of informa0on are shown. The first is implicit, and it’s the priority of the request gauged by the posi0on in the list (top issue is the top priority). The second through fourth are in columns: “Component” is the product or service (e.g., DynECT Managed DNS, Dyn Standard DNS), “Summary” is the idea, and “Status” is… status.
- 80. Feature Requests If the status is “Open”, it means no one is looking at the feature request at the moment. If the status is “In Progress”, it’s likely in ac0ve implementa0on by teams. If it’s anything else (e.g., Sales Review, Legal Review, etc.), the request is running through the “Product Lifecycle Process” used by the director team to evaluate and spec out requests.
- 81. Feature Requests “In Progress” requests generally have their work defined already in the form of a func0onal specifica0on and stories on the current sprint or the product backlog. Each team has a prac0cal limit for the number of requests “In Progress”; as each effort wraps up, the next highest priority request is taken on.
- 82. Feature Requests Three 0mes a week, directors and execu0ves review and adjust the priori0es of requests using the “Priori0ze” link. We’ll discuss priori0za0on later on, but for the moment, it’s worth no0ng that unless you’re in a priori0za0on mee0ng, you shouldn’t change anything here.
- 83. Feature Requests Only the top 10 priority feature requests are shown on each gadget. To see lower priority requests, click the link at the bojom that says “N matching issues”. This will take you into JIRA, where you can explore all feature requests.
- 84. Feature Requests Clicking a summary will take you to the feature request in JIRA, where you can comment on the request, watch the request to be emailed about changes, vote on the issue and more.
- 85. Feature Requests Want to request an improvement to something we already have? Click “Improvement Request”. Want to request new func0onality that we do not already have? That’s a “Feature Request”, so click “Feature Request”. The links take you into JIRA with the screen promp0ng what’s required. Let’s look at this in more detail.
- 86. Feature Requests Crea0ng a request takes you to JIRA, and requires you to specify a summary, a component (select drop down for op0ons, they’re the products, and you can specify more than one!), assignee (leave as “automa0c”), reporter (yourself, search by name).
- 87. Product Backlog Let’s look at the third secJon in detail: Product Backlog. The goal of this secdon is to see what work is queued up to work on next, defined in a format anyone can understand: stories define what value is gerng to what person for what reason, and bugs define funcdonality that use to work but currently does not. Have it open? Good!
- 88. Product Backlog • Few porJons to pay aFenJon to: – What work are the teams going to take on next? – What are the teams going to take on for the rest of the year at a high level? – How do we prioriJze the work to be taken on?
- 89. Product Backlog Grouped by teams; at top are the DNS teams, at bojom are the Email teams. Within DNS, we can see short-‐term backlogs for DNS Performance and Op0miza0on and DNS New Product Development. Within Email, we can see short-‐term backlogs for Email Deliverability and Email Engineering. Let’s zoom in on DNS.
- 90. Product Backlog For each team, the backlog contains the sorted list of bugs and stories that will be taken on when the current sprint wraps up. The top 10 items are shown. The top N items define the next sprint, where N changes based on the complexity of the work that can be completed in under two weeks.
- 91. Product Backlog To see beyond the top 10, you can click the “N matching issues” link at bojom.
- 92. Product Backlog The short term backlog defines the work to be done between the next sprint and about 6-‐8 weeks out. The long term backlog focuses on larger efforts that we know we’re going to take on, between about 2 months out to 1 year out. Clicking the tabs changes the view.
- 93. Product Backlog There are two priori0za0on links; one shows priority of just the stories and bugs, while the other includes the technical and business sub-‐tasks that describe the work to be taken on in detail.
- 94. Current Sprint Let’s look at the third secJon in detail: Current Sprint. The goal of this secdon is to show what teams are working on now in the current sprint, who’s working on what, and how efforts are progressing within the sprint (e.g., efforts to be done, in progress, in QA, and complete) toward a release. Have it open? Good!
- 95. Current Sprint The rows indicate teams (e.g., Data, Marke0ng, DNS P+O, Email Deliverability, etc.). The columns indicate states of stories and bugs as they progress through. As a sprint is worked on, issues move from lea to right.
- 96. Current Sprint Here is the work currently being taken on by the data team, described in the form of stories and bugs.
- 97. Current Sprint Here is all of the work across the teams that has yet to be started. Moving lea to right, the work goes through the states: In Progress, In QA, and finally Done. When the work is released to produc0on at the end of the sprint, it’s removed from the view.
- 98. Current Sprint To move work from one state to another, click the “Current Sprint Rapid Board with Stories and Bugs” link. That will take you to JIRA, where you can drag and drop your work into the next state.
- 99. Current Sprint To see the individual technical and business sub-‐tasks that compose the stories and bugs, and how those individual items are progressing, click the “Current Sprint Rapid Board Including Tasks” link.
- 100. Get your own dashboard! If you’re running Confluence and JIRA and would like to get started with this dashboard, email me at cvw@dyn.com and I’d be happy to send you the code and help you set it up!
- 101.