A simple product summary to help requirements

I was speaking to a crew who were struggling with regression testing and after interrogating them they finally admitted that a large part of the reason they were struggling was that they did not really understand what they were testing.

I was shocked and horrified so I wandered off.

Soon after I spoke to some business analysts who were struggling with an agile project. They alleged that the agile approach they were using did not allow enough time to capture the requirements properly. But guess what, they broke down under interrogation and admitted that a large part of the problem they were having was that they did not really understand the product they were building.  Apparently the evil agile people had forced them to write stories about the system before they had time to understand it.

Continue reading “A simple product summary to help requirements”

Using MoSCoW to prioritize ideas

I have been on a lot of projects in my time and I used to prioritise ideas or requirements as “high”, “medium” or “low” importance.

If people classified their requirement as low,however, we would record the requirement in a long list, thank them for their idea and then never talk about it again.  If they classified it as medium then we promised get to it in “phase 2”, which meant after we ran out of money.

People learned over time to classify all of their requirements as high priority so we started adding new classifications like critical or super ultra high, which didn’t help at all.

Continue reading “Using MoSCoW to prioritize ideas”