I have been working in Scrum teams for quite some time now, and I am a big fan of the method. One thing I always wondered about however is why product owners seem to change their minds so often after a sprint delivery.
The last few months I got the chance to experience Scrum from the product owner’s side and it really confirmed the value of the method to me and also taught me a valuable lesson…
About this post: This guest blog was written by Brigitte Meijer, Information Analyst & Requirements Engineer at BmIT. She is a valued collaborator of ours who we regularly hire for consultancy. We have asked her to share her views on our recently released plugin, the XSD Viewer for Confluence. This is what she wrote:
We are currently developing webservices and an ebMS interface for a customer. This involves making a lot of XSD’s…
Previously we wrote the functional and technical documentation for these interfaces in MS Word, made tables explaining the elements by hand and used a development tool to create schematic images. This was a lotof work and it was very difficult to keep the XSD and the documentation in sync.
Documenting an XML Schema Definition (XSD) can be a tiring process. You first load a file in an XSD viewing tool like XMLSpy, you then make screenshots of the areas of the definition you want to display and finally, you paste them into your documentation. Of course you have to repeat the entire process whenever the file changes in any way.
Avisi prides itself on being a cutting edge development organization so we felt strongly we needed to find a solution to this problem. Since we use Confluence as our documentation platform we chose to build a Confluence plugin: the XSD Viewer for Confluence.
The job of a requirements engineer is to find out what people need as opposed to what they want. Customers however don’t buy what they need, they buy what they want.
If your goal is to sell sofware solutions that solve the real needs of your customer (and it should, if you are in for a long term relationship) make sure you are armed for the battle against the want. You start with a disadvantage, but if you resist, ultimately everyone wins.
A user story can be a perfect short description of the use case, but it does not contain all the details you need for implementing, testing and maintaining the software.
A use case describes the what of the user story in much greater detail. And as a requirements engineer, when writing a use case description, you are forced to make it thoroughly logical – with no open ends.
So… user stories are great to uncover the who and the why, but you still very much need use cases to describe the what.
People tend to talk a lot about software quality, but what is it exactly? Sure, there are a number of tools that promise to measure your software’s quality level. Some of them are certainly quite good at helping you visualize their results. Sonar for example, is a tool that combines multiple matrixes to make up a quality index. The output is a value from 1 to 100%. This is great because we are all quite number oriented in software. We get that a quality index of 5% means the software sucks and that 100% means it’s the best piece of software ever.
Gathering requirements is not that simple. It can be a bit of a wild hunt actually! As I mentioned in a previous post, the challenge does not lay in detailing the perceived solution, but in uncovering the true problem… That said, your requirements should always enable your team to create software that is more than satisfactory to the stakeholders.
When designing and building a house it’s obvious you’ll ask the customer to specify what he (or she!) wants.
Making software is no different. You need to ask, ask, ask and then ask some more. It’s unlikely you’ll get answers to problems right away. You usually have to dig deep. So go ahead be annoying and ask “why” until you get to the root of the problem.