You may consider a Sprint successful if all the tasks are developed and the build doesn’t break. Or you may consider it a success if all the acceptance tests passed. Or you may consider it a success if the customer is really excited and can’t wait until the next Sprint. These are all indicators of good success. But I want to add still another success criterion. On top of all these measurements, I consider the Sprint a success if all supporting players consistently used their strengths to get the job done.
Being a maximizer, I am consistently looking for ways to improve the software development lifecycle and one of the best ways to improve the lifecycle is to improve the experience of the people who are responsible for bringing the cycle to life. But how do you measure “improved experience”?
At the beginning of each Sprint make three statements about how you propose to use your strengths to achieve Sprint and corporate goals. For example 1) I will use my analytical strength to Optimize System Quality by taking ownership of the test tasks; 2) I will use my command strength to Optimize Application Architecture by confronting those who do not follow the selected architectural patterns; 3) I will use my input strength to Optimize Implementation by noting the various styles being used in the application code.
At the end of the Sprint, during the Sprint Retrospective, rate your success according to the following criteria (or improvise) and use the ratings to develop your skills & expertise so that each successive Sprint will bring you even greater fulfillment.
I met my Goal!
- strongly agree
- strongly disagree
Reasons for ratings of 3, 4, and 5
- lack of skill (e.g. tried but didn’t do as well as expected)
- lack of opportunity (e.g. no tasks available)
- lack of time (e.g. other tasks took priority or PTO)
A couple of months ago, I purchased “User Storied Applied” by Mike Cohn. I glanced through it, primarily looking for similarities between use cases and user stories to give me a point of reference. I found my point of reference pretty quickly in chapter 12 in a section titled “User Stories Are Not Use Cases”. In this section the author indicates that there are 4 major differences between use cases and user stories 1) their scope 2) their level of completeness and 3) their longevity and 4) the proclivity to include UI details in use cases.
In my experience, use case scope has presented difficulty in the SDLC. Yes, use cases are structured and sized to deliver business value but the business value in a single use case could take the entire SDLC to complete. This is a problem in use case driven projects because project tracking is based on use case completeness. I have found that using use case scenarios instead of use cases is helpful (if everyone on the project is on board) and our author agrees “that a user story is similar to a single scenario of a use case” as long as the scenario represents a successful path through the use case.
There are a couple of solutions that address the problem of use case completeness. One that I am particularly fond of is the use of use case outlines that are completed JIT. For example, in the inception phase the actors and use cases are discovered and documented in the use case model. Each of the use cases are then outlined to discover their basic flow as well as their alternate flows – each given only a name and brief description – and only those flows that have been identified as architecturally significant are detailed. But… 80 to 90% of the remaining flows are completely detailed prior to the beginning of the construction phase.
Use case longevity has proved to be even more frustrating to me. Not so much because the use case was used throughout the SDLC, but because so many resources (people & time) are used to create them, organizations tend to want to keep them around even longer and use them as post production artifacts too.
Keep UI details out of the use case! How many times have I said that? I probably cannot count for it has been a struggle in every single project I have been involved in. (Anybody out there remember me saying that!?)
So why user stories? I think the best reason is to eliminate use case documents. Project team members could not get on board with using use case scenarios because the scenarios were imbedded in use case documents; they just could not mentally decouple a scenario from its parent. And if there is no use case document there is no place to stick a UI specification. And, even more importantly, if there is no use case document there is no propensity to keep it and maintain it for all eternity. The author also lists 4 other reasons 1) they emphasize verbal rather than written communication 2) they are comprehensible to all parties 3) they are the right size for planning and 4) they work for iterative development.