Agile/Scrum- Performance and Scope

Performance and Scope
We (all of us) at times forget some of the most important things that are related to your project, performance is one of them. I have been on many projects that we are so wrapped up in the development of the application that we forget about the “performance” of the application in real world use. Your product owner expects no DEMANDS a certain level of performance from the end product delivered by your agile/scrum team. I have found that the product's performance is closely associated with how well you control the agile/scrum project scope. Scope control is an element of the project that will affect all of the other project elements in the project. If you fall into the trap of “scope creep” you will lose control of the project, also it will affect the speed and the quality of the agile/scrum project. As risks increase so will the schedule, that will in effect will increase costs, thus slowing down the late and over budget project. Scope Creep is like a wave that will wash along your entire project and will affect all elements of it, all in a bad way.

From the beginning you must document with the project owner/business all specifications in the project scope. The scope is the foundation of the overall project and control of this element will help your team in controlling other aspects of the project. Try to document all the specifications, hardware, servers, etc and the softer specifications like how and who will use the application, usability, etc. It’s not that easy but try to include a user from the product owner/business side for the definitions of the “customer acceptance” or the “user experience” as it pertains to the application in development. Document the answers to each of the questions below and add them to your scope plan, cover each specification singularity not as a group. And every time you receive a request to change the scope, you must ask these questions all over for each change. As a scrummaster try to define the performance specifications and go deeply, again ask lots of questions, here are a few to try (below)

Performance and Scope Questions
1. Is there a separate specifications document available?
2. If there are no specification documents available, can you define the specification based on the information you have available?
3. If you have a separate specifications document is available, is the detail sufficient to develop the product?
4. Are the specifications from a reliable source? Product owner/business/end user
5. Who approved the specifications? Product owner/business
6. Does your project team have the tools, skill sets, resources, and budget to build or buy a product that meets the specifications?
7. Do you have a clear definition of each specification? (hardware/software)
8. Do you have agreement between you and the Product owner/business and/or customer on the details of each specification?

Popular posts from this blog

Burn Down vs. Gantt Chart

Agile/Scrum- Communication Plans

Cost Control Agile/Traditional