Wiki - Scrum Documents

Meeting Topic: Scrum Documents - How Much is Enough?

Attendees:  We were a group of five, did not get the names but it was just the right people!

If you were in the group, please add your name and email address here

Time/Date/Location: 

2 PM, March 17, 2000, Orlando, Scrum Gathering

Notes

• Two audiences for documents in our projects
  1. Teams need documents for strategic needs (for the enterprise, for the future)
  2. and for tactical needs (what the team needs today)

• Some people have regulatory requirements that mandate large documents
• Projects last for 2 years, need to have documents that will support this
• How are people getting user doc done? In a sprint? Outside the sprint?
  • Suggestion - Tech writers are not part of the sprint, but are usually ready to write when the software is ready, use docs that are available from the sprint team. Personalities also fit this model so they are successful at this even though they are not part of the sprint team per se

• Clients want to see templates for scrum documents - does anyone have any they are using?
  • One company has a wiki site with their scrum process. After teams get used to this, allow teams to work on their own and post their process

• Where to keep sprint docs? With teams or with sprints or products?
• When details are hashed out in the sprint planning, where does this get doc'd?
  • If you have an automation regression suite, this can help by taking a snapshot of the product at that time and this becomes the reference for design standards

• How are standards kept and referenced?
  • One participant is a slow moving agile adoption organization. They have scrum coaches, who work out of project management office, they help identify which documents/best practices are for working in scrum. Mostly working with the developer side. Also have technical architecture guru who define standards for architecture - this is saved in a company website. Users can search for standards. Then the owners of the standards (standards are published out there for the team's reference) will do a review at some point in the sprint to make sure it's adhered to. This is a process for handling standards that pertains to many sprints at a fundamental level. Who updates the central repository of standards? The team can fill out an exception request and the owner will review the request, make sure team understands it as written and then approves or denies the request.
  • Owner does the standards review in the sprint  - the team will request this when ready.
  • Another example - style guide for the user interface is written and linked to the Product Backlog Item. Team should be using this when they do their work.
  • In both cases, the team has the responsibility to get the standards and use them
  • In more specialized teams, the specialist know which standards to follow

• Where to store documents? Working with 3 teams who are dependent on each other. Example stylesheet changes, it gets written up and then put into sharepoint and then disappears. That team now understands the new change, but the next dependent team who works in the same code area is not aware of the change.      Teams are running in parallel - handle this with a scrum of scrums meeting. This can help. Improve exchanges (as per Mike Cohn)
• 7 projects with 3 new acquired companies. There is a technical best practices person.
• Example - where would you document an rgb value for  a color for your website project? If using tdd, can doc in the test case. The earlier in the process it gets doc'ed, it will be less expensive. Doc both in the standards and test cases.
• What level of detail should be included in feature requirements? No information is being provided on functional requirements.
• Should you have to look at the code in order to figure out what the product should do?
• Who are the requirements for ? Test acceptance criteria for stories is good. Developers can tell Product Owners that they need more detail
• Stories can be too big, difficult to get all the details needed.
• One team is using a product wiki with each story as a wiki page - using tfs with backlog items - using team sites with wiki's - using area paths in tfs as features - mapping test cases to these area paths in order to know what needs to be tested if something changes later. Linking pbi's in tfs to sharepoint site doc
• Where are docs being stored and what formats are being used for requirements?
  • One team is using a word doc, but have problem with everyone not having the latest version so would like to use a wiki.
  • People are also using lotus notes which gives a common place to get the latest version from.
  • Wiki pages in sharepoint will show you what changed from version to version. This could be another solution

• People are using user stories as the high level of the requirements, and then still doing more detailed requirements and are still calling these requirements. Doing separate docs in some cases for business rules, data elements, core requirements that will always stay the same (like customer name, ssn #). Business analysists write the more detailed requirements.
• Remote delivery in excel sheet, requirements matrix with # of test cases, and user story - cmmi process. Other ways to link stories to requirements, data elements, traceability matrix.
• Receive customer request and then put this into the requirements matrix, use this to determine level of effort
• Is anyone using automation testing and replacing the writing of test cases with the automation scripts? Are you still writing test cases if these scenarios are also being scripted?
  • Still have developer level tests - this team would rather work slowly and get things right rather than be on time and be 80% accurate.

• Can you support team needs who come later to maintain or support system?
  • One team creates a virtual binder with all docs needed, the docs are based on templates, they do a transition with the team to create these docs. Made this a priority - it's a virtual document with defined pieces. It is stored on the network and there is only one version. This is used for future teams to support bugs and to do small enhancements in the future. This has worked really well with new team members who join.

• Some teams have cross tier architecture and very specialized roles
• Montreal team has daily standup meeting in the morning for bug support and is working with some projects in agile
• Server component, client component, minimal installation requirements - defects that come in from the field usually have very good documentation from the customer about what doesn't work as expected so dev team can use this to fix the bug. Problem is when new coding breaks something else and there is no documentation to refer to in order to prevent this. They create a regression product backlog item to test anything that needs regression testing - qc meets with teach team to identify what regression testing needs to be done along with the change. Details are being doc'ed in this product backlog item - example testing 20 config settings out of 100 settings due to changes made. Put results into the product backlog item so test results are known; can evaluate risks based on this.
• Still losing track of requirements changes sometimes
• Hard to get product owners used to doing "just in time" user stories and leaving more details requirements for later
• Timebox planning meetings - if product backlog items with more detailed requirements are not good enough for the team to understand the work, this is the product owner's problem.

Tuesday, March 17, 2009