I believe it's useful to have the IT staff involved. It is tough to do, but necessaryfor the success of the workshop. I have had to ask a sponsor or PM to remove IT people who do not comply. BUT, if they start to participate, I kindly remind them that this workshop is about requirements, not solution, so hold your peace. The only exception I make is to allow IT people in the workshop as observers only they may geniunely be interested in in hearing what goes on. You do certainly do NOT want IT people in your workshop already telling the business users what is doable or not that will limit what the users will say, and annoy them in some cases. Once they agree the requirements were captured correctly, it's done.Īfter that, the IT team can use the Requirements for estimating and design. After you may need to clean up, resolve any outstanding issues, and get the same business users to review before anyone else sees them. In an effective Requirements Discovery Workshops, all the Requirements are captured right then. You are facilitating, and I assume the scribe is there for real-time documentation of the Requirements, or as close as you can get. (Executive Sponsors are ther to kick-off the workshop, but they don't need to stick around after that.) The key people in the workshop are the Business Users, they are the source of Requirements. (Sometimes facilitators are from IT too). When it is Requirements, no one from the IT team needs to attend if they are designers or coders or testers. Is it really design that is the outcome of the workshop? Or is it Requirements? If that latter, I call that a Requirements Discovery Session. Let's start with "JAD" which actually stands dfor "Joint Application Design". Your question is actually a very good one, so let's look it over. We see a lot of questions on this site that are essentially "tell me how to be a BA, because I know nothing".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |