Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My company is introducing SCRUM for new software development. I'm currently both Product Owner and a product manager responsible for the technical aspects of the software. The technical manager role is not part of the scrum team.

I'm finding there is some desire within the scrum team to treat the software development as a black box ie I should only care about user stories and business benefit.

This is an issue as the information needed to inform client discussions about the most appropriate architecture, deployment mechanisms, host system requirements etc isn't available (I'm responsible for this in my manager role). For example, the dev team may develop a system that can only be used with a particular database collation. This isn't something I'd ever anticipate so wouldn't create a user story or discuss with clients but it might be a show-stopper for the product.

What documentation and level of transparency is reasonable? The whole team is new to scrum so any advice welcome.

PS: I wonder if this dual role is a good idea. I think some team members may think the Product Owner is being a rooster which isn't my intention ;-).

share

migrated from stackoverflow.com Sep 1 '11 at 23:11

This question came from our site for professional and enthusiast programmers.

1  
Side note: It's not an acronym, so write scrum or Scrum, not SCRUM. –  Hugo Sep 2 '11 at 19:25

1 Answer 1

up vote 6 down vote accepted

What documentation and level of transparency is reasonable?

"Reasonable"?

The question shouldn't about "reasonable".

It should be about "deliverable".

information ... about the most appropriate architecture, deployment mechanisms, host system requirements etc isn't available

Then, there's a problem with what the developers think is deliverable and what you think is deliverable.

On the next sprint, include these other deliverables.

Don't be silly and ask for mountains of traditional "Big Design Up Front" documentation.

Ask for the "architecture", "deployment" and "platform" descriptions. They're easy to produce and should cover a few pages of material.

share
    
Thanks, that makes sense. As you suggest, I'm far more interested in quick, brief, "living" info than huge static docs. –  Alistair77 Sep 1 '11 at 23:09
    
@Alistair77: Be absolutely sure the developers are perfectly clear on what you need to know. It's easy to ask for too much. You can claim here that you want "quick, brief, "living" info" and still wind up demanding a traditional big-design-up-front kind of document. –  S.Lott Sep 2 '11 at 1:23

This site is currently not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .