Usability or easy-of-use has been around for a long time, but recently it is popping up in discussions more and more. Some customers need to use it, some want to use it and some should use it …
But how can we advise our customers to implement usability if we don’t do just that ourselves?
Time to investigate what usability is! 1 thing is for sure, it is a lot more than putting buttons in the right place. It’s about interviewing users, defining wire frames, design the interaction, making it an integrated part of the project lifecycle. The result should be an application, webpage or document that doesn’t need explaining and conforms to the expectations of the end-users.
How to do this, well, that is on the path of discovery, as is the impact on the entire project, timing, scope, budget and quality.
Who has already used usability within his/her projects and what are your findings?
For those who have already implemented usability, how did you fit it in the development process? What are your findings about usability? Would you do it again?
People at iAdvise have already shown a great deal of interest which will surely lead to some challenging initiatives.
One thing has become crystal clear the last couple of days:
Using Scrum in a validated (Pharmaceutical) environment requires a somewhat different approach.
In a validated environment a number of documents, that are normally not required in Scrum, have to be delivered. These documents, Functional specifications, Risk Impact analysis, … are artifacts from the classical approaches. The solution we came up with is to have a task in each single sprint that states updating these documents. This way, after every Sprint, the documents will be updated, and thus the documents will be finished after the last sprint, ready for acceptance by the Business.
However, this is not the biggest challenge in a validated environment. The people working with these projects are used to doing everything by the rule. Using Scrum, we bend the rules a little bit. For example, we don’t have the Functional Specifications signed off by the business prior to the development phase. This makes some people very nervous. Every day I realize more that this project will be more about coaching the team towards Scrum, than focusing on my task as Scrum Master.
We have started writing User Stories, this makes the analysts feel uncomfortable. They want to have everything defined up front, but that is not what User Stories do. They will have to wait until the first Sprint Planning meeting to get the details. This first meeting will be on the 1st of October …
These are my first days as Scrum Master.
The mission is clear, introduce Scrum in the Project and, at the same time, guide the Project Management Team to start using Scrum.
The first days on site it became clear that this is not going to be Scrum from the book!
A Scrum project starts with defining the Product Backlog, which comes from the User Stories, defined by the business. This concept is well known over here. It’s the way they do it that makes it special.
Writing the User Stories will be done as a Scrum project, a Scrum project within a Scrum project so to speak. Maybe not even a bad idea to start out with, but …
What about priorities? You cannot label a User Story as less important; they all have to be written before they can be prioritized.
The area’s for which the User Stories have to be written are defined, and it is also defined which area’s get priority. This way, three priorities can be defined
1. The stories that have to be ready before end September;
2. The stories that have to be ready mid October
3. The stories due after mid October.These represent 20% of the functionality, and are less important.
Thus we will start with the first priority User Stories; these have to be done by end next week, that is a short Sprint …