What are some sources of “REWORK”
- Misunderstanding of Requirements => Translation Errors
- Test Cases that are inconsistent with the Requirements
Changes to Requirements
- Updating the user interaction flow and step details that are duplicated across your Use Cases and Storyboards and Test Cases
- Updating your Wireframes, which are duplicated across multiple storyboards and test cases
How do “Use Case Storyboards” eliminate this REWORK
“Use Case Storyboards” COMBINE your “use cases”, “wireframes” and “storyboards” into one integrated deliverable
A “Use Case Storyboard” as shown below, is simply a “Use Case” where each step in the use case is associated with a UI Wireframe/Mockup. This of course includes the main flow and alternate flow steps of the use case which is very different than traditional “Storyboards”, which are only a series of linear steps. This sounds simple, but the benefits are profound.
This approach allows you to walk through, or essentially simulate your “use case”.
So what are the benefits of this approach and how does it reduce REWORK
Communicates Requirements more clearly resulting in less software development iterations
- No longer does the reader have to review a use case and then manually correlate the steps in the use case to a storyboard or even worse just a collection of wireframes not put into a storyboard.
- Instead the reader has the context of the details outlined in the use case step right beside and in context of the Wireframe associated with that step.
- In addition it strongly encourages the collaborative and combined review of use cases and UI/UX design by your BA and UI/UX teams, which will result in more accurately defined and understood requirements.
The “user interaction flow” is shared between the use case and the storyboard eliminating duplication
- As the flow changes you no longer have to update the flow definition in multiple places (ie. Use Case, Storyboard, Test Cases), reducing rework.
- It also ensures your storyboards cover all of the alternate flows defined within the use case helping ensure requirements are not overlooked
- Your storyboards will have less duplicate UI Wireframes, because common wireframes that used to be duplicated across multiple storyboards are now defined in the mainflow or parent flows of nested alternate flows.
You could even generate your test cases from your Use Case Storyboards
- The interaction flow and wireframes defined in the Use Case Storybaord are identical to what you will want for functional test cases. So using some creative algorithms you can actually automatically generate your functional test cases and they will be 100% in sync with your requirements.
STORYBOARD allows you to create Use Case Storyboards in something you are already familiar with -> PowerPoint
Create “Use Case Storyboards” in PowerPoint with powerSTORYBOARD
Learn more about powerSTORYBOARD
I will be honest, I have not answered this question in my own mind yet, but I thought it would be good to have a group discussion about the potential pros/cons of not using sprints/iterations when applying agile.
Why do I question this?…
It has always bothered me that sprints are always of the same length and we need to fit our scope of delivery to this rather arbitrary sprint length. I understand some of the values of having a fixed sprint length…but still I wonder if it is the best way.
Maybe I have been doing agile wrong for the past 10 years, but I always seem to see some challenges caused by the existence of a sprint with a fixed length.
lets start with this one…
When requirements authors (BAs / Product Mangers etc) craft their requirements they don’t really take into consideration how long things take to build when they define a requirements, story, storyboard etc. So this means the dev team needs to break down these requirements into smaller chunks and deliver only those chunks during the sprint. I typically see two issues when this happens.
1) It can often unclear what subset of the requirements the developer is actually agreeing to implement. We have tried breaking down those requirements into smaller chunks/stories, but then we just end up duplicating the statement of the requirement in multiple locations, and equally importantly this takes time that seems almost like a waste of time.
2) Sometimes what can be delivered in the duration of the sprint really is not a great logical breakdown of what we want to see delivered. For example let’s say the sprint is 2 weeks, but the work that can get done and completely tested within 2 weeks really does not make sense, but what could be done in 2.5 weeks would make sense.
I know and have applied techniques to break down the work so it fits into the sprint, but my point here is this takes time away from building the solution, and can cause confusion as to what the scope of the sprint is if not done in enough detail.
I have been experimenting with a different approach here at PowerStory where for a given product release we essentially have a continuous backlog of stories / bugs that we want in the next release and treat that release as one long sprint. That sprint might be anywhere from 1 month to 4 months depending on the goals of that release.
The result has been interesting. The net benefit I have seen is that we spend less time managing and more time defining and building the solution.
Martin Crisp CEO, PowerStory
I decided to take some time off work this week with a cruise in the Caribbean with family. It gave me some time to further explore some thoughts on Agile as a popular approach especially for product development companies like ours. This is just a rough draft of some thoughts, but hopefully it will foster some good discussion. Yeah…it turns out I am not so good at taking time off from work J
I keep hearing and reading that Agile allows you to be responsive to changing needs, but it strikes me we need to be careful how this is interpreted. This does not mean you should change your product priorities every week.
Ok, agile allows us to be responsive to changing needs, but you need to remain disciplined about product management. In my product management roles I remember fighting against the constant “must have feature requests” from our sales team on a regular and often weekly basis, or an important customer that was demanding some new capability be our top priority. This may sound familiar to those of you in the product management role, or even business analyst role within IT organizations.
A key responsibility for Product Management is to take in all of the different product ideas from multiple sources and combine that with an internally driven vision for the product to craft a product roadmap.
The point here is that you need to be careful not to get caught up in the agility of agile to the extent that you are changing you product roadmap too frequently, or you will end up with a confusing bloated product.
Current approach – too many hand-offs and deliverables
Many organizations approach to defining software requirements involve too many hand-offs and deliverables. This can lead to requirements translations errors between the different hand-offs and deliverables. In addition, the collective details of the requirements are spread across so many different deliverables it makes it harder for the developers and testers to properly interpret and understand the requirements.
For example, many organizations will take this approach…
BA / Product Manager
- The BA or Product owner elicits requirements from a customer…
- …and writes them down perhaps as a high level feature list…
- …then further elicits and documents requirements details using use cases and/or user stories and perhaps
UI / UX Team
- These use cases or stories are then interpreted by the UI/UX team…
- …to develop UI Mockups
- …and perhaps UI Storyboards
- …or even full blow interactive UI Prototypes to bring these use cases to life.
QA and Development
- Then the development team and the testing team need to interpret these UI Storyboards, UI Mockups and Use Cases to develop the code and Test Cases.
The result of this approach includes a lot of re-work and project costs due combinations of the following. Perhaps some of this sounds familiar to you.
Use Cases, UI Mockups, UI Storyboards and test cases often get out of sync with each other, which makes it difficult for the developers and testers to know what real requirements are.
- For example the use case steps may now communicate something different than steps outlined in the ui storyboard or test cases.
- UI Storyboards and/or prototypes forget to implement all of the flows outlined in the use cases, leading to a scenario where features get missed.
- Test cases are incorrect, causing false bugs to be found, wasting further time and budget.
- Missed test cases, causing bugs not to be uncovered, leading to costly production issues.
- Developers building features that are different than what the customer is looking for, leading to unsatisfied customers or additional rework.
- Another related issue is that often during the UI Storyboarding phase new requirements come up that are added to the UI Storyboard but also should be in the original use case. A lot of good intentioned teams will not spend the time to update the use cases and feature lists, furthering the confusion for the developers and testers.
What can we do to reduce this confusion and rework
The good news is that there are some reasonably simple changes we can make in our processes and deliverables that will decrease the “broken telephone effect”. The theme shared by these ideas is to reduce the hand-offs and translations.
Get the Entire Team Involved in the Requirements Early
One technique is to involve the BA, UI/UX and QA resources directly in the elicitation process with the customer. Some may even argue to include the lead developer for that domain as well. By having all disciplines represented during the interviewing process, they will all hear requirements directly from the customer, helping reduce the reliance on just what the BA documents. Another equally important side benefit is that each discipline brings a different perspective which can lead the interview process down different paths of conversation and requirements gathering.
For example the QA resource may tend to ask more questions about the requirements that related to edge conditions, or error conditions, than perhaps the BA or UI/UX resource would. In addition putting the UI/UX resource in front of the customer, will give them a chance to better understand what kinds of features are more frequently used, which is important when trying to manage the cognitive load of the end user, by ensuring the more frequently used functionality is more easily found through good UI/UX design.
This may seem like a waste of time and budget, but at least considering the benefits of doing this on the more complex portions of your application could be a good start.
My personal approach is to include the developers and QA team during the requirements walkthroughs early and well before they are done, so that they have the opportunity to provide feedback and also gain a deeper semantic understanding of the requirements and what is driving them.
Combine and evolve your Use Cases, UI Mockups and UI Storyboards into the same physical deliverable
One approach to addressing this is to combine your Use Cases, UI mockups and UI storyboards into one integrated deliverable called a “Use Case Storyboard”. A “Use Case Storyboard” is simply a use case where each step in the use case is associated with a UI Mockup.
This approach has the benefit of automatically keeping what you traditionally would have documented as a separate use case, UI mockups and UI storyboards in sync. In addition to keeping everything in sync, it turns out to be far easier to communicate the requirements during walkthroughs of “use case storyboards”, because they combine the details of a use case text along with the informative UI Mockups into one deliverable that is easy to walk through from the end user point of view. This not only helps your end customer confirm the requirements are correct, but also importantly helps reduce confusion with the developers and testers
In addition it strongly encourages the collaborative and combined review of use cases and UI/UX design by your BA and UI/UX teams, which will result in more accurately defined and understood requirements.
Adopting this approach would involve starting as we normally do by having the BA define the use case without any mention of UI specific requirements, just to capture the objective of the user in the use case and any key steps and alternate flows (or exception flows, depending on which terminology you use). Then the UI/UX team would start to attach UI Mockups to each of the steps in the Use Case to start to bring to life the UI/UX design.
Since the “Use Case Storyboard” is expressed in terms of a main flow and alternate it has the additional benefit of reducing the number of traditional storyboards, which are linear and don’t include alternate flows. For example if we took the sample “use case storyboard” above and represented it as two separate linear storyboards, the first and last steps and their UI mockups would be duplicated, leading to requirements maintenance and rework costs.
So to summarize, the “use case storyboard” reduces rework by helping you communicate requirements more clearly. In addition this approach also reduces requirements translation errors typically caused by hand-offs between deliverables and teams.
Generate Your Test Cases Automatically from Use Case Storyboards.
Instead of having your QA team manually create test cases, why not Generating test cases directly from your “Use Case Storyboards”. This has the following major benefits.
- Dramatically reduce the time it takes to create your functional test case set.
- Your test cases are 100% consistent with your requirements
- You have complete functional test case coverage
- As requirements change, you can update your test case set quickly
For example if we were to take the “Use Case Storyboard” outlined above, it would generate the following two test cases, including the UI Mockups.
Test Cases are typically written in a format of a “user action” followed by an “expected” result. If you spend a little more time up front when creating “Use Case Storyboards”, defining which steps are “user actions” and which steps are “expected results” this can used in the test case generation engine to determine which steps should be assembled into test cases as “user actions” or “expected results”.
As an industry we are always evolving how we do things. In this article I present an approach that helps reduce project costs and increase the likelihood that you will develop what your customers need. I talked about how to get your collective team involved earlier in the requirements definition process which is not really a new idea, but certainly a valuable one. However I do present the concept of a “Use Case Storyboard” that combines Use Cases, UI Mockups and UI Storyboards, into one integrated deliverable that promotes collaboration and also makes it easier to communicate requirements to your customer, developers and testers. Lastly I talked about the idea of generating your functional test cases directly from these “Use Case Storyboards” which generates some significant project savings.