A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Difference in terms of client engagement in the case of Scrum ..

Dealing with a client is one of the most important elements in making a software project successful. In the classical Waterfall method, the initial interaction with the client is mainly done by the Business Specialists / Product Management team. They interface with the client, understand the requirements, and eventually end up preparing a massive and detailed requirements document. This requirements document is signed off by the client (or rather by a set of people who represent the possible different functional areas of the client team). Based on this requirements document, a design document is drawn up and then the whole process goes through the development cycle, testing, release, end user testing, etc.
However, practical experience typically shows that end users from the client side don’t have their requirements in the form of a list of bullet points, and when faced with such a list, they are not easily able to confirm. Even when they confirm the list, it has been seen in a number of cases that there are many requirements that are not captured during the requirements phase, or there can be differences in the way that the requirements have been captured and the way that they have been designed. When the client gets an interim release, they could see issues in the implementation and would want changes to be done. If these changes are big enough, there is still the possibility of making these changes with some impact (may be minimal) to the schedule.
In many other projects, the client is really not engaged with the software company after the requirements phase and comes into action much later, during the beta phase or the user acceptance phase. However, in the situation described above, the possibility that the software that has been created matches the client requirements fully may not happen; which can lead to problems for both the client and for the software company. One would tend to think that one way to change this is by engaging with the client on a regular basis; however if you consider the classical waterfall methodology, the system of design, development and testing does not really lead to a process whereby the client can get engaged.
On the other hand, when you start using the Scrum methodology and get the client involved with the whole process with confirmation, you are basically involving the client as part of every Sprint. So, the Product Owners are engaged with the client on an ongoing basis to determine the features / user stories for every Sprint, as well as being there when the evolving product (and features done in the Sprint) are demoed to the client and the team. At this point (in every Sprint), the client can suggest changes or even point out things that are not done in the right way. By this method, continued engagement with the client helps in ensuring that the product matches what the client wants.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>