In Scrum, you go into a Sprint having already made a commitment to a number of stories. What happens when your manager, supervisor, or one of the stakeholders comes to you requesting to take on one new thing on your plate. Are you a people pleaser? Do you say ‘Yes’?
If you said ‘Yes’, you already undermined the commitment the Team made to the sprint. A better approach would be to say ‘No’. But, how do you say ‘No’ to your manager, supervisor, or the stakeholder (who might be paying the bills)?
The “No” Repertoire
In the book, Greg suggests having a ‘No’ repertoire handy. You can get to this list when faced with a situation where you have to say ‘No’, and say it gracefully. Here is my version of the ‘No’ repertoire for Scrum teams.
No. We can not take on this new Story as we are already ‘in flight’ into a new Sprint.
Yes, we may be able to take on this new Story. But, what are you willing to de-prioritize from our current Sprint?
Thanks for this new Story. We can put it on our Product Backlog, and take it on in the next Sprint if it is still your Priority.
We can take on this new Story, but are you willing to put the success of the current Sprint on the line for this new Story?
Can you please explain the business reasons behind this urgency (on this new Story)?
Why can’t this new Story wait till we get into next Sprint?
[bctt tweet=”The “No” Repertoire for #Scrum Teams! http://www.nimeshsoni.com/get-hyper-tip-learn-to-say-no/ #getHyper #Agile”]
Yes, you can say ‘No’ to your stakeholders. You just have to learn the art of saying ‘No’ gracefully!
#makeTheShift – Finishing Work and Start Creating Value
Stop starting too much work, Start creating VALUE
Too often we have too many things ‘in flight‘. With the computers in our palms and pockets, we are taking multi-tasking to the extreme! Start this new year with a promise to yourself: Promise not to start more work. Instead, shift the focus on finishing the work and creating Value.
It doesn’t matter how much work you have on your plate or how busy you are. What matters is how much Value you are creating for your customers. Adopt a Work in Progress (WIP) limit for yourself and adhere to the limit.
You will be amazed as to how much MORE you will accomplish in the new year with this formula!
Product Owner (PO) role is a very important role in Agile. She often wears many hats! She is working with Stakeholders on creating and maintaining the Value Backlog and identifying the right priorities. She is also working with the Development Team on creating Work Backlog that creates the Value that is being sought. She is essentially working as a bridge between Stakeholders and the Team, between Value Backlog and the Work Backlog. And she is acting as a bridge between the Business and the IT.
The Product Owner also sets the direction of the Initiative (or Project, if you want to call it that). She sets the direction by identifying the priorities; and she is one of the big factors, if not the only factor, that has huge influence on success or failure of the initiative.
Many faces of Product Owner
Benefits of Standard Work
Product Owner role being such a critical role in the success of your initiative, would it help to document the work she has to do? Does it add value to having documented this Standard Work?
[callout]Standardized work is one of the most powerful but least used Lean tools. By documenting the current practices, standardized work forms the baseline for continuous improvement. [/callout]
Let’s review some of the benefits quickly:
Creating standard / Standardizes the work across different teams, different people; ensuring consistency across the organization
Set expectations, certain level of expectations, branding as to what’s ‘given’ when the team/individual says a certain task is done
Sets up a common platform against which the effectiveness of the individuals can be measured
Ensure certain level of quality
Ensure that certain routine, mundane tasks get done (and don’t get overlooked due to them being ‘boring’)
Standard Work: Product Owner
Let’s start identifying the activities for the Product Owner now that we are clear on the importance of the role and the benefits of Standard Work. We can start listing out the Daily and Weekly activities, as well as the activities that need to happen when a specific event is happening, for example, Release Planning.
[tabby title=”Daily”]
Attend the Daily Scrum meeting
Did I answer (if any) questions raised by the Team members, within a few hours?
Did I resolve / remove / find work around for business impediments?
Do I need to provide Story-level CAT (client acceptance testing)?
Do I need to connect with business Subject Matter Experts / business community for any open or upcoming item?
Story Burnup
Did I update and review Story Burn up chart?
Is the team working on highest priority stories?
[tabby title=”Weekly”]
Product Backlog planning / Backlog grooming with Business stakeholders
Break Epics to Features, assign Business Value
Break features to potential User Stories
Ensure that each Story has “Who, What, Why” identified
Ensure all Features and User Stories have Acceptance Criteria (AC)
[tabby title=”For Each Sprint”]
Review charts
Release Burn up / story completion
Examine the “top line” scope, the current and projected velocity, and the anticipated date the velocity line intersects the “top line” scope. Make adjustments to scope or release date as necessary
Feature completion
Is the team working on right things in the right sequence? Is effort being applied to future features that should be applied to near-term features?
Business value completion
Examine the trend of business value per story point (RoI) being delivered. Can we sequence higher ROI features earlier in the release schedule? If only lower ROI features remain, can we end the project early? Can we remove high-cost / low return stories from features to improve the feature ROI?
Maintain Product Backlog
Re-sequence features
Examine the planned features for each release and adjust as team velocity, capacity, ROI, risk, dependencies, etc. are better understood
Create/Update/Delete Epics, Features and User Stories
As we get smarter, update the backlog with the current understanding of the epics/features/stories
Backlog Grooming with Team
Work with the Team to add sizes to any epics/features/stories that don’t have a size assigned
Ensure information dashboards are updated and visible (topline, velocity, release burnup)
Assess risks and dependencies among epics/features/stories
Collect highest-priority stories that represent approximately 125% of the teams average sprint velocity.
Ensure user stories are detailed enough with validations for team commitment.
Work with the technical Product Owner (tPO) to identify and prioritize the highest-priority/predecessor enabling (technical) stories
Develop and communicate Sprint Goal(s)
Sprint Review
Facilitate part of the review, explaining Business Scenario and Goals, and then hand-over to Team member to showcase/demo the functionality
Participate in the Sprint Retrospective with the Team
Sprint Planning
discuss the sprint commitment with the team. Hold the team responsible for meeting that commitment.
Update Vision (if necessary)
Communicate sprint/release progress to stakeholders
[tabby title=”For Each Release”]
Create/Update the Vision
Identify epics and features
Assign business value to epics and features
Group features into “minimal releasable feature sets”
[tabbyending]
Would it help to have your standard work documented? Can it help you, your team improve the productivity and deliver more VALUE for your customer?
Go ahead and document your Standard of Work. Start with this list, update it, refine it, and put your team on the “hyper Productivity” lane!
Pomodoro is the best productivity tool that you can ask for in today’s world filled with all distractions we love to call iPads, iPhones, Text and SMS, the Facebook, the Twitter and all other Social Media updates that we can not get enough of. They are hinderance when we are trying to get things done. They are distractions that derail our focus taking away our attention to non-value add tasks.
The concept of pomodoro is very simple. Timebox yourself going into an activity; typically 25 minutes at a time. Set aside the timebox of 25 minutes and commit to doing one thing and one thing only during that 25 minutes.
[bctt tweet=”An apple a day, keeps a doctor away! A tomato (Pomodoro) each time, keeps the waste away! #getHyper #Agile”]
In the Star Wars movie The Empire Strikes Back when Luke Skywalker tries unsuccessfully to rescue his X-wing fighter from the swamp and gives up, Jedi Master Yoda has these words of wisdom for him:
[callout]
Do or Do not, there is no try! You must unlearn what you have learned!
[/callout]
Scrum is no different! It is a new approach to building and delivering Products and Services. It is an approach that is relentless in creating VALUE for customers. In Scrum, you go to your Customers with a Product Increment, often and with regular frequency.
At the core of it, Scrum requires mental shift! The successful adoption starts with us unlearning the old habits and approaching with new, fresh eyes! You have to be willing to step out of the box, step out of your comfort zone, and be willing to try and form new habits.
Here are ten habits that I believe we must unlearn to be successful at adopting scrum:
Create email trails
Use Command and Control
Create disciplines and silos
Be a Hero
Sign off on a detailed requirements document
Stick to the iron triangle
Be plan driven
Be IT driven
Have a big bang delivery
Tell teams “How,” not “What”
Remember, these are the ‘bad’ behaviors, bad habits that we must break! We must unlearn what we have learned over the years, flush them out, and start on Scrum journey with a fresh approach!
[tweetthis twitter_handles=”@beyondCSM” remove_hidden_urls=”true”]Succeed at #scrum? Step out of comfort zone & unlearn what we have learned! #makeTheShift[/tweetthis]
The original article that I wrote and is published by Scrum Alliance can be accessed here
She is also working with the Development Team on creating Work Backlog that creates the Value that is being sought. She is essentially working as a bridge between Stakeholders and the Team, between Value Backlog and the Work Backlog. And she is acting as a bridge between the Business and the IT.
