For my first Scrum project, I consolidated all of the wish lists into one spreadsheet which became our product backlog. Initially, I had 4 columns: Name, Effort, Priority and Estimate. I quickly added a “reference number” column to make it easier to find individual stories.
We set up a Scrum area on the wiki. It had hierarchical structure:
The daily scrum spreadsheet had 4 Columns: team member, yesterday plan, yesterday was, today plan, and impediments. “Yesterday plan” I copied from the previous days’ “today plan’ column, the rest corresponded to the three questions of the daily scrum. I updated the spreadsheet every day, adding one sheet per day in the sprint, copying “today plan” into “yesterday plan” and updating the remaining fields according to the results of the daily scrum. Then I uploaded the file into the wiki. There are pros and cons to recording data this way (particularly related to its impact on the flow of the daily scrum), and today I would do the daily scrum differently, but the traceability was awesome.
All other documentation gets uploaded into the corresponding task for within the Sprint. Confluence had a very nice feature that it would take first sheet in the daily scrum .xls file and display it directly in the browser from a Wiki page, saving the media break of having to download the spreadsheet and opening it in a dedicated program.
The advantage of this approach is self evident: you have these tools and you know how to use them (well, actually we had some user acceptance issues with the wiki). A spreadsheet is very flexible, so you can slice and dice the data as you see fit. Data reuse is not a problem per se. Backup is handled by whatever mechanisms you have in place for your PC. (You do have a backup, don’t you?! If nothing else, copy the data to a memory stick and store it separately from your PC).
The wiki requires a lot of discipline so that you can find things. The basic Scrum flow was relatively easy, but data which did not obviously belong to a single sprint were always somehow special cases and finding them later was hard. A good search tool is a prerequisite for using the Wiki.
What finally drove us to a tool based solution was the need for a better tool manage the product backlog. The Wiki was too inflexible as a data structure and the spreadsheet was too flexible. The customer, when he had the data, could too easily change the structure of the spreadsheet. Assuring the quality of the input was a problem and we had “file locking” problems: Either the customer could update or we could update, but we could not see changes made be other until we got the spreadsheet back, nor could we update unless we had agreed with the customer that we had the writable copy.
[Previous: Managing Scrum with Paper and Cards]
[Next: Managing Scrum with Dedicated Tools]
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checkbox-advertisement | 1 year | Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category . |
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Cookie | Duration | Description |
---|---|---|
mailchimp_landing_site | 1 month | The cookie is set by MailChimp to record which page the user first visited. |
Cookie | Duration | Description |
---|---|---|
CONSENT | 2 years | YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data. |
_ga | 2 years | The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors. |
_gat_gtag_UA_42152348_1 | 1 minute | Set by Google to distinguish users. |
_gcl_au | 3 months | Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services. |
_gid | 1 day | Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously. |
Cookie | Duration | Description |
---|---|---|
NID | 6 months | NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads. |
test_cookie | 15 minutes | The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies. |
VISITOR_INFO1_LIVE | 5 months 27 days | A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface. |
YSC | session | YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages. |
yt-remote-connected-devices | never | YouTube sets this cookie to store the video preferences of the user using embedded YouTube video. |
yt-remote-device-id | never | YouTube sets this cookie to store the video preferences of the user using embedded YouTube video. |
Cookie | Duration | Description |
---|---|---|
COMPASS | 1 hour | No description |
cookies.js | session | No description available. |
S | 1 hour | No description available. |
3 Comments
The problem with Wiki and Excel is quite common. These tools are simple, but general. They do not have business logic behind, but provide frameworks to resolve simple data manipulation problems.
It is good, but what are the benefits? Wiki+Excel will not work in distributed environment and will not work for large collocated team s well. Concurrent access, real-time reporting, integration with other dev. process tools. It is just not there.
Maybe it will work for small collocated teams? Yes, sure. But for small collocated team I prefer tangible cards, white boards and markers. For me Wiki+Excel is a dead end. No benefits, more repetitive work to have all up to date, still poor reporting (take a photo of your white board and send to manager instead sending spreadsheet!)
I’d recommend using Google docs – u can have an online spreadsheet that everyone can edit live at the same time, works really well.
I used google docs to manage distributed testing once.
The customer had not defined test cases but had a team of testers. So we created a main sheet with the user stories to describe the function of the system. Then we cloned the sheet, one sheet for each tester, where s/he entered his/her test results. On the main sheet, we linked to the individual tester sheets, one tester per column.
For the limited scope of this problem, it worked quite nicely, was easy to set up and available across company boundaries, with no license fee.