Go Back
  • Scrum Starting Practices: Sprint Planning

    This may or may not be helpful to some people but i just wanted to do a walk-through of a typical sprint planning 'process' I just tried using with the current team I'm on. We have me (programmer/scrum master), a tester, a business person, a requirement writer, and various 'specialists' giving us hours here and there (mainframe, webservices, and database). I'm basically acting as scrum master and sometimes as 'product owner' in many regards. (generally the product owner situations i end up in are ones where the technical team must prioritize and the customer team does not care one way or another on the priority at that low of level)

    1. I fire up Breeze (it's basically like a Webex or typical desktop sharing utility)
    2. I get everyone connected so they can see my desktop.
    3. I launch scrumworks (our chosen tool for distributed scrum) - maybe you use a spreadsheet or story cards or whatever.
    4. I load up our PRD (product requirements document) for a particular project (usually to add to our existing 'evergreen' product)
    5. I read the first "Detailed Business Requirement" outloud or ask the team to read it on the their own. (usually they have their own copy of the word document.
    6. Create a backlog item in scrumworks that represents that requirement.
    7. Have a timeboxed discussion (i usually don't set a time limit because people already have a tough time speaking up, but if it goes on too long in silence i start asking specific people questions... like 'if you had this software in front of you and you were going to validate this requirement, what would you do?)
    8. Ask the QA people what they would plan on testing. Maybe ask the business what QA might have missed or vice versa.
    9. break down the feature/backlog item into tasks. In scrumworks i usually denote each task with a functional group and then the task. for example the backlog item might be "User can save their settings". The tasks would maybe be "Dev: build aspx page layout", "Dev: build model classes", "Dba: setup tables and sprocs", "QA: write test scripts", "QA: execute test scripts" "BIZ: user acceptance test"
    10. Once the tasks have been decomposed and estimated in 'ideal hours' i total that up and assign the backlog item that as the 'ideal hour' size. Yes most tasks can run concurrently but the point is getting a general 'complexity' or 'size' to it so i figure there's a bit of shwag to it anyhow.
    11. Ask the team if they have enough room to commit to this backlog item taking into consideration all the functional groups needed to get to "Done" on it.
    12. Add it to the Sprint or skip it depending on 10
    13. Repeat steps 5-12 as needed until no more backlog items can be committed to.
    14. Some requirements may need consolidated into one backlog item (for example if a requirement is Dependant on another, I put them together as one and see if it makes sense... sometimes then we split them back out if it makes sense to split them in a different way by 'features' instead of by layers of software)
    15. Revisit estimates on the next reasonable amount of backlog items or estimate any un-estimated backlog items in the product backlog.

    Full story

    Comments (0)

  • Why is my scrum team not reporting impediments?

    5 little things I have done to lose the scrum team’s trust

     

    1. Turned responsibility back solely on the individual reporting the impediment.
    2. Tell them that it’s ‘just the way things work’ at this company or otherwise keep status quo
    3. Lose track of open impediments. Fall through the cracks.
    4. Assign someone different work when they’re impeded
    5. Embarrass them for silly questions or use “but” language in front of peers.

     

    Things we can do to get people to report all impediments

    1. Take every single impediment seriously
    2. be genuinely concerned and interested. Note your body language.
    3. Write it down somewhere visible.
    4. Make the solution to every impediment clearly visible to the whole team
    5. Take personal responsibility to ‘facilitate’ a solution with ‘team accountability’
    6. Thank them for reporting the issue

    Full story

    Comments (0)

  • Scrum and Multitasking

    Multi tasking isn't bad... all of the impediments that force you to multi task are bad.

    Think about the last time you had the actual opportunity or reason to multi task. You were doing something, then you ran out of things you could do to move forward so you switched over to something else.

    i see it all of the time with software development. You know you need to write a user interface, so you start putting things on the web page, you start adding stuff, and it suddenly occurs to you that you don't know an answer to a question. "I wonder if they want blue or red for this?"

    "I guess I better call the business analyst/customer etc"

    so you pick up the phone and you get their voicemail. "Damn!", you think.

    You leave a voicemail message and you move on to something else.

    Now you've spent a good 10min getting ramped up into the task at hand and you're bopping along. Your phone rings. "Damn, i was on a roll!", you think.

    So now you know they want Red, and you now either go back to making that widget Red or you continue doing your second task.

    Is there no way around this dilemma?

    Well, you could make an assumption and go with red. Unfortunately, if you forget to ask them then you're going to get a defect though if they wanted blue. I guess you could risk it. Lots of us do this... subconsciously. 

    If you do that then you're wasting both your time and the testers time. These wastes are task switching and rework.


    Full story

    Comments (0)

  • Why User Stories? They help us plan and estimate.

    We use basic requirements at our work. They're of the normal "The system shall" style but not nearly so stringent. They don't read like a spec. They are pretty much "right sized" so they have that going for them. They also are fairly detailed as far as the "What".

    When i say they have the "What" part, i mean they say things like "users must be able to click on a heading to sort the field"

     

    So the "What" is this: "Must be able to sort"

    and who needs to sort?

    and why do they need to sort?

     

    What's really missing from these type of requirements is the Who and the Why. These are very important and it's something built right into the "Card" part of the user story.

    Remember, User stories are three things. They are

    1. Card
    2. Conversation
    3. Confirmation

    So the Who, What, and Why are the most basic and first part of the Card. (test objectives and size are also part of the card)

     

    as a [Role] i want [feature] so that [business value]

    or

    as a [Who] i want [what] so that [why]

    For example...

    As a job hunting i want sorting on jobs so that i can find jobs by where they are located.

    This represents the requirement.

    IMPORTANT

    This is NOT the requirement. It represents the requirement.

    It's often confusing to people so i'm going to say it a third time for emphasis...

    A user story is NOT the requirement. It simply represents the requirement for the purpose of estimating and planning.

    So why is the Who and Why relevant to estimating and planning? Because again we're only concerned with a representation of the requirement for the purpose of planning (ok i said it 4 times, shoot me).

    The who is important for planning and estimating because you're going to have to have a little bit of conversation with that person to figure out enough of the requirement to estimate it in size. Now i'm not saying you have to find out all of the details up front!

    One of the agile mantras is "Delay decisions until the last responsible moment". This is so that we can give our customer the opportunity to change the requirements and turn on a dime! Now, this "responsible moment" is very subjective! For example, i might need to know if this sorting needs to be client side or can it be server side. If it's client side, that is architecturally significant and may impact the estimate.

    The why is important because it gives us a chance to think creatively about the problem. The customer wants sorting so they can find jobs by region. Well, what about a search functionality? What about a filter? Are there alternatives to achieving their goal that may be easier? Better? More usable?

    So why user stories?

    They allow us to defer the details, to estimate, to provide options to our customer to achieve their goals and they give a concise description that represents a requirement for the purpose of planning and estimating.

    Full story

    Comments (0)

  • What employees do the scrum roles?

    Who does what role in scrum?

     

    aka

    This Organizational Chart is a Figment of your imagination.

     

     

    Life is full of epiphanies, but some are more amazingly simple than others.

     

    Scrum roles… it’s very simple.

     

    There is one product owner. This is the customer. They wantsomething.

     

    There is one scrum master. This is the coach, facilitator,and a shepherd.

     

    There is a team. These are the people who can make the thing the customer wants. Not just the builders, but everyone who can make what thecustomer wants.

     

    It’s that simple… however org charts are rarely that simple in larger organizations.

     

    Forget them. Seriously. Pretend it doesn’t exist.

    Just strike this completely out of your head.

     

    Let me explain briefly why:

     

    QA manager… are they a product owner? Nope. I won’t get intothe how and why but unless they are programming, analyzing requirements or testing, they aren’t a part of the scrum team.

     

    Development manager… are they a product owner? Nope. Same asabove.

     

    Product manager… are they a product owner? This one is a lot more tricky… well they give us the requirements. They often tell us what weneed to make. They probably even would come to a scrum planning meeting and act like a product owner… saying where to go, what to do, what the priority ofthings are. However, if you listen closely… very closely… they don’t have all of the requirements. They’re merely parroting what they’ve heard someone else say. They’re merely giving you an echo of someone elses desires. Granted, they could be making up some requirements of their own and getting them in… is that what the real customer wants?

     

    So product manager… no

     

    Relationship manager… this is unique to my work I think but maybe other companies have this. Supposedly this relationship manager is the person who brings in all the stakeholders and their goals and is the 1 single wringable neck for how things get prioritized and worked on. Sure sounds like aproduct owner doesn’t it?

     

    Nope. I say no.

     

    You are probably thinking “WTF?”

     

    Here’s a news flash. This relationship manager… they aren’tgoing to come to your scrum meeting. They aren’t going to know the actual requirements for the one epic that they prioritized as number 1 this release. They aren’t going to have the foggiest clue what to do when you say the farkle won’t feebozzle in schneezle so do you have an alternative to feebozzling it? They'll say, hmm let me get back to you on that... or i need to talk to "Fred" (ding, Fred should maybe be your PO?)

     

    So who is the product owner for your scrum team?

     

    GOOD QUESTION.

     

    You are probably sitting there with a vision statement…requirements document… business case… some sort of piece of paper with an ‘DRAFT’ stamped across the front page and a “Confidential” background on every page.

     

    You are staring at the the translation of the real productowner’s words!

     

    OK, So who are they?

     

    Go to the product manager and say “hey, this document… whowrote this?”

     

    Go to the writer of the document and say “Hey, who told you this stuff?”

     

    And keep doing all this and that until you find the real person who wants this product change… and then you simply say to them.

     

    Hey, can I borrow you for 3-4 hours to do sprint planning on such and such day? Can you be available for the next 30 days to answer questions about this thing you want? We hear it’s really important to you and we’re finally working on it!

     

    Let me know what they say.

     

    If you like how this works… go thank Mike Vizdos for this amazing epiphany he gave me.

    http://www.michaelvizdos.com/telephone/index.html

     

    Full story

    Comments (0)