Learn How to Prioritize, Pushback and Make Progress
By Poornima Vijayashanker I just finished a one-on-one with Adam, who is a student in our Lean Product Development Course. Adam is a software …
By Poornima Vijayashanker
I just finished a one-on-one with Adam, who is a student in our Lean Product Development Course. Adam is a software engineer in Florida, who works for a large software company. He often has to pull all-nighters to try to keep up with the demands of management, and he’s just tired!
Adam decided to take our course, because even though he knows how to build a product, he is tired of the inefficient practices that are in place at his company. He wanted to learn techniques to improve the product development process at his company, so that he get some much deserved R&R.
After our last class, Adam and a few other students did an in-class assignment together online. Their assignment was to create user stories for a password recovery page.
User stories describe the actions a user would perform in the product in simple English, to achieve an end goal. An example would be: As a user, I’d like to enter a username and password when registering for an new account.
Seems simple enough right?
The purpose of the exercise is to teach our students, like Adam, about scope creep.
What is scope creep?
Well it’s what happens when people don’t think through scenarios when building features. Instead they gloss over thinking that the feature is easy and can be done in no time at all!
When it’s time to ship the feature or even after, the team notices that there are new scenarios that they hadn’t thought out, or the implementation wasn’t correct. As a result, there is additional work that has to be done before the feature can really be considered complete.
In our Lean Product Development Course, we help students practice creating stories that are clear to everyone on the team (even non-technical folks) and identifying scope creep early on to avoid shipping delays.
For example, Adam and the other students did a great job of coming up with high-level stories for the password recovery feature such as:
As a user, I’d like to click on a link, to recover a lost password.
As a user, when I am taken to the password recovery page, I should be able to enter my email address.
As a user, I should be given a warning if the email is invalid or malformed.
As a user, I should receive an email with a link to reset my password.
As a user, when I enter a new password, I should be given a warning if my password is not strong enough.
But then I pushed them to get more granular! And that’s when they asked me why and what does that mean?
All of these stories are great! But they do not accurately capture ALL the work that needs to be done. It creates an illusion that the feature is simple and should be delivered on time. However, each of these stories has additional stories.
Let’s take for example one of the so-called simple stories:
As a user, I should be given a warning if the email is invalid or malformed.
What does it mean if an email is invalid? What does it mean if the email is malformed? There are additional stories that need to capture this in detail such as:
As a user, I should be given a warning if the email address does not fit the format <text> dot <extension>.
As a user, I should be given a warning if the email address contains special characters or spaces.
As a user, I should be given a warning if the email cannot be found in the system.
You get the idea…
The point behind this exercise is to demonstrate that there are more scenarios that need to be built out. It’s OK if we cannot come up with all of them early on, but when we discover them, we need to account for them.
We also teach students how to prioritize the work and to pushback!
Many times technical and non-technical students just don’t have a process in place. As a result, they get stuck having to pull nighters to satisfy the whims of management. In this course, we dig into how you can prioritize, pushback, but still make progress!
This is just one example of an in-class assignment.
Doing in-class assignments like this together helps reinforce the concepts taught in the course, and it makes it easier for the students to then apply this to their own product development teams.
Now Adam will no longer have to pull all-nighters! He has learned how to dig into stories, anticipate delays, prioritize work, and pushback on things that aren’t priorities. Here are a few other students who have experienced similar benefits after taking the course:
Sanjay – International Student and Software Engineer
If you’re interested in learning more, check out our Lean Product Development Course. We are currently accepting early bird applications for the Spring iteration, and if you have any questions or concerns you can sign up to attend an upcoming info session on March 12th at 3pm PST.
