The product application manager on the DBA team disclosed that there was an outage where a data loss occurred over a year ago which initiated a project to upgrade the hardware for this database's server. The project, which was expected to take 3 to 4 months, had stalled and been in-progress for a year. The status of the project was unknown, including what work had been done. It was a high priority for this migration to happen because another outage could happen at anytime and it was predicted that the data loss would be more significant.
The interim manager agreed this project was top priority for the DBA team and I was ready to help get a project plan in place with a "User Story Map" to get it moving along. The exercise was straightforward enough and the group seemed to understand when I walked them through how we would build it despite their not participating in previous story mapping sessions.
However trying to build a story map with a DBA, product application manager, data analyst, software developer and no product owner yielded what I will refer to as a technical work map. Which for the project at hand made sense and they felt what developed was useful. Basically in the technical work map user activities were developer activities and user stories were developer stories or tasks. Colored dots were placed on the stories to show responsibility and coordination for the DBA's, PAM, data analysts and software development. Marks would be placed in the dots to identify if a story was in progress, done, or cancelled.
Continue reading this BlogSpot at http://curiousagility.blogspot.com/2014/11/getting-it-done-with-technical-work-map.html
Follow me on Twitter @_AprilJefferon
0 comments :
Post a Comment